What Are the Four Types of Workflows?

Every time you write software that does more than serve static HTML, you're building a workflow. Data comes in, moves through a series of transformations or checks, and a result comes out the other end.

Here's the thing most teams never stop to name: there are really only four shapes that movement takes. Almost every business workflow — an approval chain, an onboarding sequence, a claims process, a CI/CD pipeline — is one of these four patterns, or some combination of them. Pick the wrong one for the problem in front of you, and six months later you're staring at a Jira ticket that says "automate the data ingestion" and an unmaintainable pile of nested if-statements and race conditions to show for it.

What Does "Workflow" Actually Mean?

At the business level, a workflow is just the defined sequence of steps a piece of work moves through — who touches it, in what order, and what has to be true before it moves to the next stage. An expense report routed for manager approval is a workflow. So is a new-hire's onboarding checklist, or a support ticket moving from "open" to "resolved."

The software version of that is more precise but not fundamentally different: data instead of paperwork, code instead of people, but the same underlying question — what happens next, and under what condition. That's why the four technical patterns below map so cleanly onto non-technical business workflows too. A state machine is just a formal name for "this request can only move to Approved from Pending, never from Rejected."

The Four Types of Workflows

1. Sequential Workflows (The Linear Path)

The most basic model there is: Step A happens, then Step B, then Step C. The process only moves forward, and a step can't start until the one before it finishes successfully. It's a strictly enforced DAG with exactly one path through it.

Where you see it: CI/CD pipelines are the classic case — you don't deploy to production if the unit tests haven't passed. Standard cron jobs, simple ETL scripts, and the early-stage steps of most ML pipelines (pull data, clean it, split it into training and test sets) live here too.

The catch: Sequential workflows are dead simple to build and reason about, which makes them tempting to use for everything. But they're rigid. If Step B fails, the whole pipeline halts. And they handle human intervention terribly — try to jam a "wait for manager approval" step into a purely sequential script, and you'll end up holding a thread or a database connection hostage for days waiting on someone to check their email.

2. State Machine Workflows (The Event-Driven Model)

If sequential workflows are about the steps, state machines are about the resting state of the data. The process isn't a straight line — it's a set of predefined states and the specific events allowed to move something between them. Forward, backward, looped, as long as the transition is one the system actually permits.

Where you see it: E-commerce order processing is the textbook example — an order goes Pending → Paid → Shipped, but it can also go from Paid back to Refunded. User onboarding flows, subscription lifecycles, and ticketing systems like Jira itself all run on finite state machines underneath.

The catch: State machines force you to explicitly define every valid transition, which is exactly what stops a cancelled order from accidentally shipping. The tradeoff is that the state management logic gets heavy fast — you need a reliable way to lock records during a transition, or two concurrent events will corrupt the state before either one finishes writing.

Also read: How to Build a Dynamic Workflow Engine

3. Rules-Driven Workflows (The Dynamic Router)

This is where it gets messy, and it's the pattern this whole blog exists to talk about. In a rules-driven workflow, the execution path isn't hardcoded as a sequence or locked into a fixed set of state transitions — the workflow evaluates the incoming payload against a set of conditions at runtime to decide what happens next.

Where you see it: Fraud detection, dynamic loan approvals, notification routing that has to branch on dozens of variables. The logic reads like: if the transaction is over $500 and from a new IP address, route to manual review; otherwise auto-approve.

The catch: Without a dedicated rules engine, this pattern devolves fast into a giant, unreadable block of spaghetti conditionals. Debugging is genuinely hard — you can't look at the system topology and know what happened, you have to reconstruct the exact state of every variable at the moment the rules fired. This is the specific gap a platform like Nected is built for: the conditional logic lives as versioned, testable rules you can inspect and audit after the fact, instead of a buried if/else tree nobody wants to touch.

4. Parallel Workflows (Fan-out / Fan-in)

Sometimes doing things one at a time is just too slow. Parallel workflows take a single trigger, split the work into multiple concurrent tasks (fan-out), and usually wait for all of them to finish before aggregating the results and moving on (fan-in).

Where you see it: Batch data processing, image resizing pipelines, pulling data from several third-party APIs to answer one user request. Distributed model training and large-scale hyperparameter sweeps — a big chunk of what people mean by "ML workflows" — are squarely parallel-workflow territory. If you're writing MapReduce jobs or using AWS Step Functions, you're already here.

The catch: Concurrency is genuinely hard. You have to handle partial failures gracefully — if you fan out to 50 workers and worker #42 times out, do you fail the whole batch or retry just that one? And every task needs to be idempotent, meaning a worker that restarts and reruns the same task twice doesn't corrupt your data.

Also read: Workflow Engine with PHP

How the Four Types Compare

If you're mapping any of this onto a flowchart or an internal doc, the four patterns also tend to use different standard workflow icons by convention — a single arrow chain for sequential, circles or rounded rectangles connected by labeled transitions for state machines, a decision diamond for rules-driven branches, and a split/merge symbol for parallel fan-out and fan-in.

Also read: Top Workflow Orchestration Tools in 2026

Where Do ML Workflows Actually Fit?

"ML workflow" isn't a fifth category — it's almost always a composition of the four above, which is exactly why it's worth calling out separately. A typical training pipeline runs sequentially through data ingestion, cleaning, and feature engineering; hands off to a parallel workflow for distributed training or a hyperparameter sweep across dozens of workers; and the whole run is tracked as a state machine — queued → running → completed → deployed, with a failed or stalled run moving to its own state rather than just vanishing. Model promotion decisions (does the new model beat the one in production by enough to replace it?) are frequently rules-driven: a threshold on an evaluation metric decides whether to auto-promote or flag the run for a human to review.

Bottom Line

Most non-trivial systems — technical or business — end up running a mix of all four. A state machine might handle the high-level lifecycle of a user account, while a parallel workflow handles their background data imports, and a rules-driven layer decides which support tier gets routed where. The trick isn't memorizing the four definitions. It's recognizing the actual constraints of the problem before writing the first line of code — don't build a heavyweight state machine for a nightly database dump, and don't try to express complex conditional routing as a sequential shell script.

If what you're actually running into is rules-driven workflows that have outgrown your codebase's patience for them, Nected is built specifically for that layer — rules that stay readable, testable, and auditable as the conditions multiply.

FAQs

What happens when a human needs to intervene in a workflow? 

Don't pause a sequential script and hold a thread open waiting on an email reply — that's how you run out of worker nodes or database connections. Use a state machine instead: move the record to a "Pending Approval" state and end the active process. When the approval comes in, an event picks it back up.

Can these workflow types be combined? 

Yes, and in most real systems they are. A state machine might track a user's subscription lifecycle, and the moment it hits "Cancelled," that transition triggers a parallel workflow that fans out webhooks to Salesforce, Stripe, and an internal analytics pipeline at the same time.

Do I need a dedicated workflow engine like Temporal or Airflow? 

Not right away. If a cron job and a status column on a database table get the job done, ship that. Bring in a dedicated engine once retries become unmanageable, you need real observability into a complex DAG, or you're tired of hand-rolling partial-failure handling and state recovery.

Are ML pipelines a separate, fifth type of workflow? 

No - they're usually a layered combination of the four: sequential for data prep, parallel for distributed training, and a state machine tracking the run itself, sometimes with rules-driven logic deciding whether a new model gets promoted.

What's the difference between a business workflow and a technical one? 

Not much, structurally. A business workflow — an expense approval, an onboarding checklist — follows the same four patterns as a software one; it's just people and paperwork moving through the states instead of data and code.