Hi @MartinF,

I believe the issue you're encountering stems from the relationship map jumping from the first table to a second one. While this type of relationship works in substitution maps, it typically doesn't function with standard metadata relationships used in business rules.

To achieve your goal, I recommend creating a view that joins task_event, task, and request. You can then join task_event to this view, which will give you access to req_type for your business rule. Keep in mind that business rules cannot be triggered directly from a view, so it's important to maintain the join between task_event and the view, with task_event remaining as the triggering table.

Also, don’t forget to:

• Add custom metadata for the view.
• Mark the fields used in the business rule as force select.
• Consider limiting the view to only include requests where the status is not 'CO', 'CL', or 'CA'.

Here’s an example of what the view might look like:

!--scriptorstartfragment-->

CREATE VIEW [YourViewName] AS

SELECT

    te.event_sequence,

    te.task_id,

    t.request_id,

    r.req_type,

    r.status

FROM

    task_event te

INNER JOIN

    task t ON te.task_id = t.task_id

INNER JOIN

    request r ON t.request_id = r.request_id

WHERE

    r.status NOT IN ('CO', 'CL', 'CA');!--scriptorendfragment-->

Best Regards,

Morris

Thanks ​@Morris for the detailed explanation. I shall apply that to our solution tomorrow and hopefully resolve the issue.

Hi ​@Morris ,

It didnt work unfortunatetly. I set my view up as described (plus a few extra fields). I set up the metadata for each field in the view similar to below for each field (I set all fields to FORCE SELECT. (Can you explain the purpose of this setting please?)

I also updated the join in the metadata for TASK_EVENT

Finally business rule update

Hi ​@Morris ,

Further to the above, just checking the server log, the first two BR input fields get hit with a match, whereas the 3rd field (from the VIEW - REQ_TYPE) does not even appear.  When i had the mapping to REQUEST, that field from REQUEST was showing in the Log but not matching

Martin

​@MartinF ,

It should be working, when I tested I created the same view and same custom metadata. I setup a business rule using the value from the view. When I execute the rule I can see the evaluation of the input param, and see the result of the test. In my test I am updating the note field on the task. See below I have included a screen shot of the server log entry of the req_type from the view getting evaluating and returning as true.

what are the settings for the custom process for the business rule?

As for the force select option

• Force Select deals with the FSM implementation of Optimistic Record Locking.

• When working with a record, before anything is done, the record is queried.  Values are selected in the query for comparison, a snapshot of those values is made, and the values are kept in memory.  For a pending change, just before committing the database change, only the Force Select fields are re-queried and if there are any differences between the new query and the snapshot query, the Optimistic Record Lock is applied.  If a field changed, the exception: “Row ({table} {table}, (xxxxxx)) was changed after it was selected. Reselect and try again.” occurs, which is known as a “Row Concurrency Error”.  A field that is not designated as Force Select in the new query is automatically assumed to be null, so if the snapshot query has a value, the Row Concurrency Error will occur.

• In general – Set Force Select to Y for any field used in custom metadata, to avoid Row Concurrency Errors.

• More specifically - Set Force Select to Y for any field that may change from business rules, metadata, policies, integrations, imports and external messaging, but not for fields only changed in the smart client, because the screen manager includes all screen fields in its own comparison queries.

Best Regards,

Morris

Hi ​@Morris ,

Thanks for the detailed explanation on Force Select.

Regarding the Business Rule settings. The BR is not attached to a custom process, but onto factory rule 08 (Task Event Notification) Does it have to be on a Custom Process?

Regards,

Martin

Hi ​@Morris,

I just tried setting up a Custom Process but it will not accept any value for the field (REQ_TYPE) for the View??

Am i missing something, somewhere else?

Martin

​@MartinF ,

Please provide screen shots of the custom metadata for the view, including the column defs. Its my guess that there is likely a misspelling somewhere?

Morris