How to create a conditional workflow?

Branching lets a workflow follow different paths depending on conditions you set, or run several actions at the same time, instead of always running in a single straight line. Three branch types are available — if, switch, and parallel — and any branch type can be added inside another.

1. Click the plus icon where you want your workflow to branch

2. Choose a branch type from the menu: Add condition (if), Add switch, or Split in parallel

   

Option 1: Add condition (if)

Routes down one of two paths, true or false, based on a condition.

1. Set the Operator, controlling how the condition is evaluated:

   All of (AND)

   Any of (OR)

   Not

   Contains

   Equals

   Not equals

   Greater than

   Greater than or equal

   Less than

   Less than or equal

   Is one of

   All of (AND), Any of (OR), and Not are recursive, they let you nest and combine multiple conditions together, rather than comparing a single pair of values. For example, "All of (AND)" can group several Equals or Contains checks so every one of them must be true before the branch proceeds.

2. Fill in the Value and Compared to fields — both are required. Type {{ in either field to insert a variable from an earlier step (e.g. step1.hrEmploymentStatus), or to use a built-in function like concat(), coalesce(), date_add(), or now().

   

3. Steps added under true run only when the condition is met, steps under false run otherwise. Both paths merge back together once complete.

Option 2: Add switch

Compares a single value against multiple possible cases.

1. Set the Value to compare, a variable path such as user.team

2. Add one or more cases, each with a name and a value to match. E.g. is_engineering matching "Engineering", is_sale matching "Sales"

   

3. Corma routes to the first case whose value matches, or to default if nothing matches. In this example, an engineering user's account gets created on GitHub, a sales user's on HubSpot

Option 3: Split in parallel

Runs two or more branches at the same time, rather than choosing between them.

1. Branches are named branch1, branch2, and so on by default, unlike if or switch, which name branches by outcome - but these names can be renamed to something more descriptive

2. Click directly on a branch's label to rename it. Names can only contain letters, numbers, and underscores — no spaces, hyphens, or symbols. An invalid name is silently rejected and reverts, with no error shown, so double-check it took effect.

   

3. All branches run simultaneously, not one after another

4. You can add as many branches as you need; there's no fixed cap

5. A parallel split can also be nested inside one of its own branches, for cases where one path needs to fan out further while the others continue on their own

   

All branch types merge back into a single path once complete, and any branch type can be nested inside another for more advanced logic.

Scoped variables

A step can use variables from any step that comes before it, including steps outside its own branch, from before the branches split. A step cannot reference a variable from a different, parallel branch, since that branch may run at the same time or not be evaluated at all.

See [How to use variables in workflows] for the full guide on referencing step outputs.

Monitoring branching runs

The live run graph mirrors the exact structure built in the editor, including which path a run actually took. Each step shows a status marker:

• Green checkmark: completed

• Red X: failed

• Skip icon: the step ran, failed, and was manually skipped so the run could continue

• Grayed out: the branch wasn't activated for this run at all (its condition wasn't met, or a different case/branch was taken)

  

If a run has any failed steps, a Retry button appears at the top of the run, re-running just the failed steps.

Putting it all together

Branch types aren't limited to one at a time. A single workflow can combine if, switch, and parallel splits, nested inside each other, to handle more complex logic.

Here's a real example:

1. Get user data runs first, pulling the fields the rest of the workflow will branch on.

2. An if condition checks two conditions (any) — routing to true or false.

3. On the true path, a switch checks step2.isArchived, routing to case_1 or default. Both cases merge back together.

4. Once merged, a second switch checks step2.team, routing to case_1, case_2, or default.

5. After that switch resolves, the workflow splits in parallel into branch_1 and branch_2, which run different actions — here, one branch waits while the other changes the user's IdP status.

   

Each level merges back into a single path before the next branch begins, so the workflow stays easy to follow even with several branch types stacked on top of each other.

Tips: Start with a simple workflow (one trigger, one branch) and add complexity once it works. Always check Previous Runs after your first execution.