Workflow Conditions

TBD FIXME: Explain how the different conditions work.

Hidden and Hard to find Features

Comparing Last Modified By User and the current Assigned User

When defining the conditions we have access to all the fields of the main module of the workflow and all its related entities on the left-hand side of the condition, but on the right-hand side, we can only access the fields directly related to the main module, not the fields of the related entities.

In fact, the use cases for this type of conditions is very limited. In all the years that we have been working with coreBOS this has rarely come up and we usually solve it with some additional code for the specific case.

Based on this question from a forum member:

We would like to set the "Workflow for Ticket Change, not from the Portal" workflow to NOT send emails when the last modified user is the same as the assigned to the user. If a person working on the ticket puts some notes in there, we do not want an immediate email to themselves. But, if someone else adds notes, we do want the assigned to the user to get an email.

To solve this use case, which is common, we have enhanced coreBOS (starting at commit 9a5307 to support accessing the fields of the "assigned to" user of the main module.
It is ONLY for the fields of the "assigned user" because those are already present when evaluating the condition, no extra effort is needed except picking them up.
The syntax is a little different to make the code easier, maybe we will enhance that someday to work as the left-hand side of the condition. Currently, the syntax has to be:
assigned_user_id : (Users) {field name}
where {field name} has to be the internal field name of the user module. For example to access the user name we would use user_name and to access the first name we would use first_name.

Once applied the code change detailed here, we can answer the question above as seen in the next image:

To accomplish this we simply need to do an empty or not empty check on any non-empty field in the related module. So, for example, if we need to launch a workflow on the Inventory Details module only when the record is related to a Sales Order, then we will check the Related To field of the Inventory Detail module for the Subject field on the Sales Order. If the Inventory Details record is related to a Sales Order then this field will have a value, if the record is related to some other module, the SalesOrder field will be empty.