Workflow execution: Sequential vs. Parallel
Atomicwork’s event-based workflows help automate processes triggered by specific events performed by users, such as request creation or updates to request attributes. Workflows can automatically notify your team, request approvals or trigger actions in third-party apps.
Workflows are triggered by user-initiated events, system-generated events or actions from other workflows.
In Atomicwork, workflows triggered by an event can be executed sequentially or** in parallel**.
-
Sequential execution: Matching workflows are executed one after another in the order in which they are configured.
-
Parallel execution: All matching workflows are executed simultaneously.
The chosen execution model—sequential or parallel—applies globally across all workspaces in your organization and cannot be configured per workspace.
This article explains the key differences, behaviours, and best practices for choosing the workflow execution model that best fits your organization’s needs.
Sequential workflows
In sequential workflows, all workflows triggered by the same event are executed one after another, in the order they were configured. This ensures controlled and predictable execution, ideal for cases where workflows depend on each other or need to run in a specific sequence.
The key behaviours for sequential workflows are:
-
Execution order: The triggering event is matched against all workflows in the system and the sequence of matching workflows are compiled, according to the order in which they are configured.
-
Approval handling: If a workflow enters an approval state, execution of workflows in the current sequence is paused until the approval is resolved.
-
Failure handling: If a workflow fails to execute successfully, no further workflows in the sequence are executed, and the sequence is terminated.
Advantages of sequential workflows
-
Improvẻd control and readability: Sequential workflows are useful to ensure your most critical workflows run first.
-
Easier troubleshooting: You can troubleshoot issues faster by quickly identifying exactly where the sequence of workflows failed.
Parallel workflows
In parallel workflows, all workflows triggered by the same event are executed simultaneously. The order in which workflows are configured does not affect the order of execution. This enhances workflow execution speed by enabling workflows to run independently.
The key behaviours for parallel workflows are:
-
Execution order: The triggering event is matched against all workflows in the system and the list of matching workflows are compiled irrespective of their configuration order.
-
Approval handling: If a workflow enters an approval state, the platform will pause only that workflow until the approval is resolved while continuing to execute other matching workflows.
-
Failure handling: If any workflow fails to execute successfully, other matching workflows will continue to execute.
Advantages of parallel workflows
-
Improved speed: Parallel execution enhances the speed of workflow execution by processing multiple workflows at the same time.
-
Better scalability: Parallel execution can handle high volumes of workflows without delays caused by sequential dependencies.
Additional considerations for workflow execution
Handling new events when workflows are paused on approval
When a workflow enters the approval state, in sequential execution, the entire sequence pauses until the approval is resolved, while in parallel execution, other matching workflows continue to execute.
If a new event occurs while a workflow is paused on approval, the platform will not initiate workflows for this new event until the approval state is resolved. This behaviour applies to both sequential and parallel workflow execution. For example, if a request is updated to change its assigned agent group while its approval workflow is still pending, workflows associated with the reassignment will not be triggered.
Note: Please reach out to the team if you want the platform to honour new events when a workflow is paused for approval, on either sequential or parallel execution.
Workflow execution on deleted request attributes
When a request attribute used in a workflow’s conditional check is deleted, the condition is treated as false during execution. The workflow will continue by executing subsequent steps defined under the false branch. For example, consider a workflow that checks if the “RAM required” attribute in a laptop service request is set to “128 GB” to determine the appropriate vendor. If the “RAM required” attribute is deleted, the workflow will interpret the condition as false and proceed accordingly.
Key differences between sequential and parallel workflows
|
Behaviour
|
Sequential workflows
|
Parallel workflows
|
Execution order
|
Workflows are executed one-by-one in the configured order
|
Workflows are executed simultaneously
|
Approval handling
|
Pauses all subsequent workflows
|
Other workflows continue to execute
|
Failure handling
|
Terminates execution of workflow sequence at the point of failure
|
Other workflows continue to execute
|
Ideal usecase
|
For processes with dependencies
|
For processes that can be executed concurrently
By understanding the differences between sequential and parallel workflows, you can design efficient automations tailored to your organization's unique needs.