> For the complete documentation index, see [llms.txt](https://developer.collibra.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.collibra.com/workflows/designing-workflows/processes/process-execution.md).

# 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.                                                  |

{% hint style="warning" %}
Synchronous script tasks are attributed to the user who starts the task. Asynchronous script tasks are attributed to the [workflow user](/workflows/designing-workflows/processes/process-execution/the-workflow-user.md).

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.
  {% endhint %}

{% hint style="info" %}
To perform actions as a specific user, use the `runAsUserById()` or `runAsUserByUserName()` methods of the [**Users** bean](/workflows/designing-workflows/processes/process-execution/beans/users-bean.md).
{% endhint %}

## 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](https://flowable.com/open-source/docs/bpmn/ch07b-BPMN-Constructs/#exclusive-jobs).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developer.collibra.com/workflows/designing-workflows/processes/process-execution.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.