Graph-Based Workflows
Linear workflows break when the real world has branches. Graph-based workflows model processes as nodes and edges: what happens next depends on conditions, not a fixed sequence.
- Graph = nodes (steps) + edges (transitions). What runs next depends on state.
- Linear: A → B → C. Graph: A → B or C depending on outcome. Loops back to A if needed.
- Useful when: qualification has multiple paths, steps can retry, or order isn't fixed
- State machine: each node knows valid next nodes. Invalid transitions = bugs.
- The goal: model real processes—including the messy parts—in code.
Real-world example
Lead qualification: different paths based on intent
A lead comes in. Maybe they're sales-ready. Maybe they need nurture. Maybe they're a partner, not a customer. The path branches—and sometimes loops back.
- Linear would force: Contact → Qualify → Nurture → Convert. But what if they're already qualified? Or a partner?
- Graph: Contact → [Intent check] → Sales path | Nurture path | Partner path. Each path has its own steps. Nurture can loop: Nurture → Re-qualify → Sales or back to Nurture.
- Nodes = actions (send email, update CRM, run AI analysis). Edges = conditions (if score > 0.8, go to Sales).
- The workflow engine follows the graph. State tracks where we are. No hardcoded "next step"—the graph defines it.
- Real processes have branches and loops. Graphs model that. Linear workflows fake it.
Graph-based workflows match how decisions actually flow—branching, conditional, sometimes circular.
- Multiple paths based on conditions (qualification score, intent, product type)
- Steps that can retry or loop (nurture → re-qualify → nurture again)
- Processes where order isn't fixed (some steps can run in parallel or in different orders)
- Complex branching: "if A and B, go here; if A and not B, go there"
A graph-based workflow is often implemented as a state machine: each node is a state, edges are valid transitions. The current state + event determines the next state. Invalid transitions (edges that don't exist) are rejected. That structure prevents impossible flows.
- More expressive than linear—can model real complexity
- Harder to visualize and debug—need good tooling
- Execution engine must handle cycles (infinite loops are a risk)
- Testing: need to cover branches, not just the happy path
- Forcing a linear workflow when the process has real branches—you'll hack around it
- Allowing invalid transitions—state machine should enforce the graph
- No cycle detection—a loop with no exit can run forever
- Treating the graph as static—processes evolve, the graph should too
Building workflows with complex branching?