Using the Parallel Native Action

the parallel native action in swimlane turbine allows orchestrators to execute multiple paths in parallel, waiting for all branches to complete before continuing downstream this action is ideal for workflows requiring simultaneous processing of tasks with synchronized results overview the parallel native action enables simultaneous execution of multiple actions, optimizing workflows that require concurrent processing by ensuring all parallel tasks complete before proceeding, the action provides precise control over complex playbook flows key benefits of the parallel action native action integrated directly into the playbook builder for streamlined workflow creation concurrent processing enables simultaneous execution of multiple actions, reducing overall processing time synchronized results ensures that all branches complete before the workflow continues, maintaining workflow consistency no connector needed operates within swimlane without external integration wait feature provides a visual indicator showing that the playbook is waiting for parallel branches to complete before proceeding understanding the parallel action using the parallel native action, you can execute multiple paths simultaneously, wait for them to complete, and then continue the playbook flow the action provides on success , on failure , and on complete paths based on the outcome of the parallel branches how parallel actions work entrypoints all entrypoint actions defined in the parallel group are executed simultaneously when the parallel action starts conditional entrypoints entrypoint actions can have conditional if expressions if an entrypoint's condition evaluates to false , that entrypoint is skipped and will not execute branch execution each entrypoint starts its own branch of execution actions within each branch can chain to other actions using on success , on failure , and on complete paths synchronization the parallel action waits for all entrypoint branches to complete before proceeding this includes waiting for all actions in each branch's execution chain result aggregation the parallel action aggregates results from all completed actions within the group if any action in any branch fails, the entire parallel group is marked as failed if all actions succeed, the parallel group is marked as successful wait node a visual wait indicator appears in the playbook canvas, showing that the playbook is waiting for all parallel branches to complete important notes about parallel execution failure behavior if any action in any branch of the parallel group fails, the entire parallel group is marked as a failure, and the on failure path is executed success behavior if all actions in all branches succeed, the parallel group is marked as successful, and the on success path is executed completion once all branches complete, the wait node completes, and the playbook continues downstream based on the parallel group's outcome (on success, on failure, or on complete) nested actions you can use loops (loop native actions), conditionals, and other actions within parallel groups action chaining actions within parallel groups can chain to other actions using on success , on failure , and on complete paths, allowing complex workflows within each branch action flow options within parallel groups within a parallel group, each action can follow flow paths on success executes when the action completes successfully on failure executes when the action fails on complete executes regardless of success or failure note you cannot use on complete with on success or on failure in the same action each action can have its own independent flow paths adding and configuring the parallel action when you drag and drop a parallel native action onto the playbook canvas, the wait visual indicator automatically appears, signifying that the playbook is waiting for all parallel paths to complete configuration steps add entrypoints add one or more entrypoint actions to the parallel group these actions will execute simultaneously when the parallel action starts each entrypoint can have a conditional if expression if the condition evaluates to false , that entrypoint will be skipped configure branch actions within each branch, add actions that chain from the entrypoint using on success , on failure , or on complete paths each action within a branch can have its own flow paths to chain to subsequent actions configure parallel group outcomes configure the parallel group's on success path to execute when all branches complete successfully configure the parallel group's on failure path to execute if any action in any branch fails optionally configure the parallel group's on complete path to execute regardless of success or failure test execution test the parallel execution to ensure all branches execute as expected verify that conditional entrypoints are evaluated correctly confirm that failure handling works as intended note the wait node ensures that the workflow pauses until all actions in all branches are completed before proceeding to the parallel group's outcome paths examples example 1 simultaneous data processing scenario process user data and send notifications simultaneously drag and drop the parallel action onto the playbook canvas add two entrypoints entrypoint 1 update user records action entrypoint 2 send notification action configure each entrypoint to execute independently the update user records action can chain to a log success action on success the send notification action can chain to a log notification sent action on success configure the parallel group's on success path to proceed to the next workflow step only after both branches complete successfully configure the parallel group's on failure path to handle errors if either branch fails result both tasks run concurrently, reducing overall execution time compared to sequential processing example 2 multi endpoint api calls scenario call multiple apis in parallel to gather data for a report add the parallel action to your playbook add multiple entrypoints, each making a different api call entrypoint 1 http request to fetch user data from service a entrypoint 2 http request to fetch product data from service b entrypoint 3 http request to fetch order data from service c each http request action can have its own error handling using on failure paths configure the parallel group's on success path to aggregate all api responses after the parallel group completes successfully, use a transformation action to combine the data and generate the report result all api calls execute simultaneously, significantly reducing the time needed to gather data compared to sequential calls example 3 parallel file processing scenario process multiple files simultaneously for faster completion use a loop action to iterate over an array of file paths within the loop, add a parallel action add entrypoints to the parallel group entrypoint 1 read file action entrypoint 2 validate file action (if needed) entrypoint 3 process file action configure each entrypoint to chain appropriately (e g , validate file chains from read file on success) configure the parallel group to wait for all file processing steps to complete before moving to the next file in the loop alternative approach if you have a fixed set of files, create separate entrypoints for each file in the parallel group result multiple files are processed concurrently, reducing overall processing time troubleshooting parallel group always fails if any action in any branch fails, the entire parallel group is marked as failed review all branches to identify which action failed and why entrypoints not executing check if entrypoint actions have conditional if expressions that evaluate to false these entrypoints will be skipped unexpected execution order remember that entrypoints execute simultaneously, but actions within each branch execute sequentially based on their flow paths (on success, on failure, on complete) wait node not completing ensure all branches have proper completion paths if a branch doesn't have a clear end point, the parallel group may wait indefinitely performance issues too many parallel branches can consume resources consider limiting the number of concurrent branches or using loops with parallel processing instead best practices handle failures gracefully define clear on failure paths for individual actions within branches configure the parallel group's on failure path to handle cases where any branch fails use error handling actions to log failures and provide context use conditional entrypoints wisely leverage conditional if expressions on entrypoints to skip branches when not needed ensure conditions are well tested to avoid unexpected skipping of branches limit complexity avoid overly complex parallel structures that may become difficult to manage and debug consider breaking complex parallel workflows into smaller, more manageable parallel groups test thoroughly validate each branch independently before running the complete parallel workflow test scenarios where some branches succeed and others fail verify that conditional entrypoints behave correctly monitor performance track execution times and optimize for efficiency, especially when processing large data sets concurrently be aware that too many parallel branches can consume system resources design for independence ensure branches are independent and don't rely on each other's execution order or results if branches need to share data, use variables or published data rather than direct dependencies use appropriate actions parallel groups work well for independent operations like api calls, file processing, or data transformations avoid using parallel groups for operations that must execute sequentially or depend on each other