Process execution

The workflow engine executes the process in a transactional way, advancing until it encounters a wait state, such as a timer event, in each active path of the execution. Subsequent tasks, sub-processes, and call activities are executed in a single transaction, and if one fails, the entire transaction is rolled back.

Asynchronous activities

You can have tasks, sub-processes, and call activities run asynchronously to split execution into smaller units of work. The benefit of an asynchronous activity is that it is part of a separate transaction, and if it fails, the actions that were performed before it are not rolled back.

The Workflow Designer provides two independent properties to control where transaction boundaries are placed around an activity:

Asynchronous

Places a transaction boundary before the activity starts. The activity runs in a separate background thread, isolated from the steps that preceded it.

Leave asynchronously

Places a transaction boundary after the activity completes, before the process advances to the next element. This ensures the completed state is committed immediately, preventing the activity from being re-run if the engine restarts.

The following table summarizes how these properties affect transaction boundaries:

Setting	Transaction break point	Effect
Neither property set.	None.	Fastest execution. The activity runs in the same transaction as its surrounding steps. If it fails, the entire transaction is rolled back.
Asynchronous set.	Before the activity starts.	The activity runs in a background thread. A failure does not roll back the steps that ran before it.
Leave asynchronously set.	After the activity completes.	The completed state is committed before the process moves on. The activity is not re-run.

Synchronous script tasks are attributed to the user who starts the task. Asynchronous script tasks are attributed to the workflow user.

Notwithstanding the above, the type of actions that the scripts invoke determine whether Collibra checks for permissions or not:

• If the script invokes synchronous calls, such as domainApi.removeDomain or workflowInstanceApi.startWorkflowInstances, the actions are performed within the workflow context. The users who start the task do not need roles with permissions that allow the task to complete.

• If the script invokes asynchronous calls, such as importerApi.importExcelInJob or domainApi.removeDomainInJob, the jobs run outside of the workflow context. The users who start the task need roles with permissions that allow the task to complete.

To perform actions as a specific user, use the runAsUserById() or runAsUserByUserName() methods of the Users bean.

Exclusive activities

By default, all activities run as exclusive jobs and cannot be completed at the same time as another exclusive activity that belongs to the same process. This ensures the workflow engine performs all activities sequentially. You do not need to change this behavior, as the built-in capabilities can manage different scenarios. You can learn more about the logic behind exclusive jobs in the Flowable documentation.