--- title: Using the Parallel Native Action slug: using-the-parallel-native-action docTags: createdAt: 2025-08-11T11:13:48.000Z --- 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 1. **Entrypoints:** All entrypoint actions defined in the Parallel group are executed simultaneously when the Parallel action starts. 2. **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. 3. **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. 4. **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. 5. **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. 6. **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: 1. **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. 2. **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. 3. **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. 4. **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. 1. Drag and drop the Parallel action onto the playbook canvas. 2. Add two entrypoints: - **Entrypoint 1:** Update User Records action - **Entrypoint 2:** Send Notification action 3. 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. 4. Configure the Parallel group's **On Success** path to proceed to the next workflow step only after both branches complete successfully. 5. 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. 1. Add the Parallel action to your playbook. 2. 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 3. Each HTTP Request action can have its own error handling using **On Failure** paths. 4. Configure the Parallel group's **On Success** path to aggregate all API responses. 5. 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. 1. Use a Loop action to iterate over an array of file paths. 2. Within the loop, add a Parallel action. 3. Add entrypoints to the Parallel group: - **Entrypoint 1:** Read File action - **Entrypoint 2:** Validate File action (if needed) - **Entrypoint 3:** Process File action 4. Configure each entrypoint to chain appropriately (e.g., Validate File chains from Read File on success). 5. 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.