Branching in Workflow | A Guide to Every Concept, Explained

Most business processes aren't a straight line. A customer request might need three completely different handling paths depending on who sent it. An order might need five things to happen at once, not one after another. A report might need to wait for two separate pieces of data before it can even start. This is what branching in workflow is about: giving an automated process the ability to split, wait, repeat, and choose instead of just running top to bottom.

The idea behind branching in workflow actually comes from software development, where developers have used Git branching for years to manage multiple versions of the same codebase without anyone's work overwriting anyone else's. A workflow builder like Monkedo applies that same branching model to business processes except instead of a developer typing a command, you connect visual blocks, and instead of a Git history, you get a workflow that runs the same way every time, automatically.

Let's go through each part of branching in workflow one at a time, with a different, concrete example for each.

Push vs. Pull: Two Ways a Workflow Moves Data

Every branching workflow is built on top of two very different ways one block can hand data to another.

Push connections are the default. Think of a relay race where each runner starts running the moment they get the baton, a block finishes its job and immediately "pushes" its result forward to whatever is connected next. This is how most of a workflow runs: request comes in, block does its thing, pushes it to the next block, and so on down the path.

Pull connections work the opposite way. Instead of waiting to be pushed, a block reaches backward and asks, "give me that value now, only when I actually need it." Imagine a block that's about to send a confirmation email and, right before sending, pulls the customer's name from an earlier step instead of that name being pushed forward the whole time, sitting there unused until needed. Pull connections only evaluate the specific earlier blocks required to answer that request; unrelated side paths connected to those blocks in between are simply ignored.

Knowing the difference matters because it changes how you debug a workflow: if something pushes and nothing happens downstream, the problem is forward in the path; if a pull request comes back empty, the problem is somewhere backward.

Sequence and Parallel Paths: Doing Things One at a Time vs. All at Once

Not every branch in a workflow needs to run one after another.

• Sequence flow is the simplest: block A finishes, then B runs, then C. Picture an employee onboarding workflow: create the account, then send the welcome email, then assign the training course. Each step depends on the one before it finishing first.

• Parallel flow is different: one output feeds several branches that all fire at the same time. When a new order comes in, you might want to update inventory, notify the warehouse, and send a receipt. None of these three need to wait for each other. They all kick off in parallel, in the order their connections were added (and you can reorder them anytime in the builder).

• Sequence and parallel combined is where it gets more interesting. Picture a workflow where payment verification must fully complete first (a sequence), and only after that finishes does it branch out in parallel to generate the invoice and print the shipping label. The engine always finishes the first connected sequence before starting the next parallel branch.

Multiple Inputs and Outputs: How a Block Decides When to Run

Blocks in a branching workflow don't always have just one way in or out, and the rules for handling that are worth understanding.

• Multiple outputs are evaluated top to bottom, exactly as they're arranged on the block. If a block has three outgoing connections, the first one executes first, followed by the second, then the third, this ordering is what makes complex branching predictable instead of random.

• Multiple inputs work differently: if a block needs data from two separate paths, say, a "generate monthly report" block that needs both sales numbers and marketing numbers, it won't run until both paths have delivered their data. If one path stalls upstream, that block simply waits, and the workflow won't silently guess or skip ahead.

• Single input, multiple paths converging (re-entry) is a more subtle case: if two different branches both lead into the same block, that block runs every single time either branch reaches it, not just once. This is useful when you want the same downstream action (say, sending a "thank you" message) to run regardless of whether the request came from a new-customer path or a returning-customer path.

Conditional Branching: How a Workflow Makes a Decision

This is the heart of branching in workflow: the Condition component, which acts like a traffic controller for your data.

Here's exactly how it behaves:

1. It checks each rule you've defined, in order.

2. The moment one rule matches, the request is sent down that output — this is first-match routing, not "check everything and pick the best one."

3. If nothing matches, there's always a default "Otherwise" path, so a request never just disappears or stalls the whole workflow silently.

Example: A loyalty-discount workflow checks a customer's tier. Gold gets a 20% coupon, Silver gets 10%, and anyone who doesn't match either tier falls through to "Otherwise" which sends a generic welcome discount instead. Three outcomes, one condition block, zero manual sorting.

Condition blocks can also work as filters: if the incoming data doesn't meet the rule, execution on that specific branch simply stops there. Nothing moves further down that particular path, while everything else in the workflow continues normally.

Loops Done Right: Why Circular Connections Are Dangerous

A very common mistake when people first try to repeat an action is connecting a block's output back into an earlier block, hoping to create a loop. This creates a circular flow and it's genuinely dangerous: without a stopping point, it can run forever, burn through API limits, and crash the whole automation. Because of this, Monkedo Automation Software blocks any direct or indirect circular connection outright. A workflow built this way is flagged as invalid and won't run at all.

Instead, repeating something safely uses dedicated components:

• Iterate Table takes an entire table of data (think a spreadsheet of leads) and processes it row by row. One output gives you the current row's data, another tells you the row number, and a separate "Done" output only fires once every single row has been processed.

• Iterate List does the same thing for a simple list instead of a table. For example, going through a list of email addresses one at a time and sending each one a message.

• Repeat is for when there's no list or table at all, just a number. For example, retrying a failed request up to three times before giving up.

All three share the same structure: one output that fires during each pass through the loop, and a separate output that only fires once everything is finished. That separation is what keeps "things that happen during the loop" cleanly apart from "what happens after the loop is done". No accidental double-processing, no early exits.

A Few Rules That Keep Branching Workflows Reliable

Once you're combining several of these ideas, push and pull, sequence and parallel, conditions and loops, a handful of rules keep everything predictable:

• Never fake a loop with a circular connection. Always reach for Iterate Table, Iterate List, or Repeat instead.

• Remember multi-input blocks wait for everything. If one of the required paths never delivers data, that block waits indefinitely, so double-check that every path leading into a multi-input block actually completes.

• Pull connections only look backward for what's needed. A pull block ignores unrelated branches sitting off to the side of the path it's tracing.

• Always set an "Otherwise" path on condition blocks. Without it, an unexpected value can silently stall the entire workflow instead of just falling through gracefully.

Branching in Workflow: Bringing It Together

None of this requires writing code but understanding what's actually happening underneath makes a huge difference once your workflows get more complex than "if this, then that". Push and pull decide how data moves. Sequence and parallel decide what happens at the same time versus one after another. Multiple inputs and outputs decide when a block is actually ready to run. Conditions decide which path a request takes. Iteration components decide how something repeats safely.

In Monkedo No-Code Automation Software, all of these pieces are visual blocks you connect directly, the same branching power that a developer gets from git branching and merging, built for anyone who needs a process to handle real-world complexity without ever opening a command line.