When do you need a graph instead of a linear workflow?
View details →
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.
Graph vs. state machine
View details →
Tradeoffs
View details →
Common mistakes
View details →
Building workflows with complex branching?