The conditional event will listen to the changes in form fields and, in case that the condition defined on a conditional event is met, the path established as exit of the conditional event will be executed.
A typical use case for this event is to interrupt User Tasks, without the users intervention.
The conditional event will always be listening to the changes as long as the task to which the conditional event is associated to has any active instances. For this reason, if a process instance hasn't reached the task where the conditional event is placed, the conditional event won't be listening to the field.
The change in fields is produced when a task is completed or when a process instance is updated through API. Therefore, if you change a field and save the changes, the conditional event won't realize about the change you introduced.
In case the condition is met and...
The conditional event is interruptive, then the task will be cancelled and the process instance will follow the path defined after the conditional event.
The conditional event is non-interruptive, then the task will not be cancelled; rather, it will start a parallel path.
Conditions can only be defined based on form fields.
Useful cases
Parallel approval
On certain occasions, parallel approval of certain departments of an organization over the same instance is necessary. It might be that a single rejection cancels the approval process entirely. In this case, it wouldn't make any sense that the other approvers keep seeing the approval task in their Inbox when the instance wasn't approved. For cases like this, it would be useful to have conditional events that cancelled all other approval tasks if one of the departments rejected the instance.
Example:
We have 3 departments: Department 1, Department 2 and Department 3.
Condition: If one department rejects the document, it is rejected entirely.
To be able to reproduce this behavior, the workflow should be the following:
If Department 1 rejects, cancel:
Approval Department 2
Approval Department 3
If Department 2 rejects, cancel:
Approval Department 1
Approval Department 3
If Department 3 rejects, cancel:
Approval Department 1
Approval Department 2
The conditional events of the 3 tasks will be:
If you establish the conditions for this conditional event based on a Yes/No type field, the system will evaluate if the "true" or "false" conditions are met as soon as the flow reaches the parallel tasks, producing unwanted results. We recommend that you establish the conditions based on combo box values (e.g. 'Accept' and 'Reject') and not based on a Yes/No type field.
Finally, you should add the following conditions to the Approval exit path of the exclusive gateway:
Keep in mind that this feature is exclusive for PRO and Premium plans.
A typical use case for this event is to interrupt User Tasks, without the users intervention.
The conditional event will always be listening to the changes as long as the task to which the conditional event is associated to has any active instances. For this reason, if a process instance hasn't reached the task where the conditional event is placed, the conditional event won't be listening to the field.
The change in fields is produced when a task is completed or when a process instance is updated through API. Therefore, if you change a field and save the changes, the conditional event won't realize about the change you introduced.
In case the condition is met and...
The conditional event is interruptive, then the task will be cancelled and the process instance will follow the path defined after the conditional event.
The conditional event is non-interruptive, then the task will not be cancelled; rather, it will start a parallel path.
Conditions can only be defined based on form fields.
Useful cases
Parallel approval
On certain occasions, parallel approval of certain departments of an organization over the same instance is necessary. It might be that a single rejection cancels the approval process entirely. In this case, it wouldn't make any sense that the other approvers keep seeing the approval task in their Inbox when the instance wasn't approved. For cases like this, it would be useful to have conditional events that cancelled all other approval tasks if one of the departments rejected the instance.
Example:
We have 3 departments: Department 1, Department 2 and Department 3.
Condition: If one department rejects the document, it is rejected entirely.
To be able to reproduce this behavior, the workflow should be the following:
If Department 1 rejects, cancel:
Approval Department 2
Approval Department 3
If Department 2 rejects, cancel:
Approval Department 1
Approval Department 3
If Department 3 rejects, cancel:
Approval Department 1
Approval Department 2
The conditional events of the 3 tasks will be:
If you establish the conditions for this conditional event based on a Yes/No type field, the system will evaluate if the "true" or "false" conditions are met as soon as the flow reaches the parallel tasks, producing unwanted results. We recommend that you establish the conditions based on combo box values (e.g. 'Accept' and 'Reject') and not based on a Yes/No type field.
Finally, you should add the following conditions to the Approval exit path of the exclusive gateway:
Keep in mind that this feature is exclusive for PRO and Premium plans.
Published on: 01 / 11 / 2018