> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.itential.com/itential-platform/2023-2/studio/workflows/parallel-branches/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.itential.com/_mcp/server.

# Work with parallel branches

> Understand how parallel branches work on the Itential Platform workflow canvas, including task execution outcomes, tasks that never run, and revert transition behavior.

After a task finishes, the workflow follows any transitions whose binding values match the task's finish state. This can create concurrent execution paths, which is a pattern known as *parallel branching*. For example, if a task has two outgoing success transitions, the workflow follows both when that task succeeds.

Control of a workflow becomes more complicated when parallel branching is introduced. Avoid parallel branching whenever possible.

## Before you begin

Before proceeding, note the following:

* This page uses foundational concepts introduced in [Creating and Running Workflows](/itential-platform/studio/workflows/create-and-run-workflows).
* Some example workflows contain tasks and transitions highlighted in solid gray. This denotes a task or transition that will not be used upon workflow execution. This is for documentation purposes only — it is not visible in normal canvas operation.

## How parallel branching works

The following example shows two tasks that both provide input to an **Evaluation (Eval)** task. Because the two upstream tasks run concurrently, it's impossible to predict which finishes first. This is an inherent challenge of parallel branching.

A *path* is a series of tasks that begins with the **Start** task and ends with the **End** task. When parallel branching is used, a single task can belong to many paths.

![](/_fern-img/a6db6e14e1b9edf1eb75611eb2840a566addf8405c15f562e2daf8280b1acde5.webp)

## Possible outcomes for multiple inputs to a task

When there are multiple incoming transitions to a task, there are three possible outcomes: all inputs are received, one input is received, or no inputs are received.

### All inputs received

A task does not wait for a specific transition binding value before executing. Rather, a task executes when all of its preceding tasks have executed and chosen a path. Even if the chosen path differs from the one drawn on the canvas, the workflow can proceed as long as the previous task has executed or declared itself as never going to execute (see [Tasks that never run](#tasks-that-never-run) below). If all incoming transitions run, the subsequent task runs.

![](/_fern-img/13300d4d7ced8802e72c07b460f292d436b6639d204b174a311f7c12a0526201.webp)

### One input received

When at least one incoming transition occurs, and even if all other transitions are no longer possible, the subsequent task still runs. Any task references that do not exist evaluate as null. In the example below, this causes the **Evaluation** task to take the failure (red) transition path instead of the success (green) path.

Recognize the potential for confusion this causes when designing workflows. When the transition in the right path between **Stub** and **Eval** shows success (green), a designer might assume the only way the workflow advances is if that condition occurs. That is not the correct interpretation of how a workflow runs.

As shown below, the **Stub** task chose a path at runtime (shown in gray) — the task completed, but since the result was not green (success), it has done as much as it can. The left (green) path was chosen and the **Evaluation** task is now free to execute. Any references to the right parallel path's **Stub** variables evaluate as null.

![](/_fern-img/0fe1084ef96fbbd5666af2c126d1cec9b4d78b93def3f7e5100256fb228162bb.webp)

### No input received

When neither incoming task succeeds, the subsequent task never runs. If this is the only task that leads to the **End** task, the job will fail.

![](/_fern-img/af7d2f69ac43d2a7ad8fe81c17c57a5cfb54f8ffc9d6a87f93529f1236056833.webp)

## Tasks that never run

If a task never runs, it still notifies subsequent tasks to determine whether they should run, based on parallel branching logic. For example, if a **Stub** task errors, it notifies all connected tasks that rely on a success transition that those transitions will never be taken. The next task (e.g., the first **Query** on the right parallel path) then notifies its subsequent task that it will never run, and so on. This notification chain continues until the **End** task or a task with multiple inputs is reached. Careful attention to all parallel paths is necessary to prevent a job from never completing.

![](/_fern-img/c83a82864b0091b14d3908fd6da652c8243d47bdaf5a62015103bc6c2721b1d7.webp)

If one of two incoming tasks to a subsequent task never runs but the other succeeds, the subsequent task still runs — even if it may not have all the necessary data. In the example below, if the **Stub** task fails, it notifies **Query** on the right path that its transition will never run, and **Query** in turn notifies the second **Query** that its transition will never run. The **Evaluation** task is notified that the right path will never run and can look to its other inputs. Once the left path runs, the **Evaluation** task sets references for the unexecuted right-path **Query** tasks to null and performs the evaluation.

![](/_fern-img/5cfdba1b1897aa0199a5e3e1bd6b307eb1cfe659094255f458f40465748dbda4.webp)

## Revert transitions in parallel branching

Determining execution order becomes more complex when a workflow contains both a revert transition and parallel branching. When designing such a workflow, you must separate how the workflow looks visually from how it actually flows through its paths. When a revert transition occurs, all tasks on the path from the revert's destination task to the **End** task are reset and executed again — even if they had already executed due to traversal of a different parallel path.

Using a revert within a parallel branch can cause all subsequent workflow tasks to run multiple times (1 + the number of reverts). This is expected behavior — plan your workflows accordingly.

### Example 1

In the workflow below, a task has two paths that lead to a shared **Evaluation** task. The right path contains its own **Evaluation** task, which fails the first time. A job variable is then set to a value intended to cause the second run to succeed, but the transition from that variable is a revert back to the **Evaluation** task — so only after the revert does the second execution yield a success.

![](/_fern-img/5fe7548ac638a4cd18ec5c5b8102ee7a97a0ef1022b97755ad9cc8bded015ba7.webp)

Due to the first execution of the right-path **Evaluation** task failing, the workflow goes to a task with a revert transition. The first **Evaluation** task notifies the shared **Evaluation** task that the path between them will never run.

### Example 2

While the revert scenario is unfolding on the right, the left path executes and reaches the shared **Evaluation** task (where both paths converge) and runs for the first time. Because both preceding tasks have chosen a path, the shared **Evaluation** task runs — but in this case it fails because it does not have the correct data from the right path. A failure path to the **Query** task is then executed.

![](/_fern-img/b03e9eb501b9e65d3952580e693599ad910e5bdaaa87636de8dd7fe13f3b910d.webp)

### Example 3

When the right path reaches the revert transition, it resets all tasks subsequent to the first **Evaluation** task along its path and starts executing again. This causes the shared **Evaluation** task to run a second time. To avoid scenarios like this, find an alternative to using revert within parallel branching — such as converting the workflow to run sequentially or using a child job to handle the revert logic.

![](/_fern-img/c8edeac344c23dd37127b709054c87e6531c113eb5bdc9adfdb1db305b1c66fb.webp)

## Revert transitions in parallel branching with child jobs

When a revert transition is used in a workflow that contains parallel paths, the revert may also revert over a running child job task. This does not stop the previously running child job — it instead launches a second child job.

Using a revert within a parallel branch can cause multiple instances of the same child job to run simultaneously. Avoid this when possible.

In the workflow below, the **Stub** task has parallel branches to both a **ViewData** manual task and a **childJob** task. If the manual task is worked before the child job finishes, the job reverts to the **Stub** task, which succeeds and then executes the **childJob** task again. This does not cancel or replace the initial child job — it starts a brand new child job while the first continues running to completion. If the previous child jobs are no longer needed, cancel them manually.

This same behavior applies when manually reverting over a paused child job.

![](/_fern-img/87a1a9fb29a51ff4a3c2fea4b1d7ce821eb5e43738880313a224a49ec533c529.webp)

> Understand how parallel branches work on the Itential Platform workflow canvas, including task execution outcomes, tasks that never run, and revert transition behavior.