Article
State Systems vs. Process Systems: Why Only One Can Have Parallel Tasks
Understanding the fundamental difference between state-based collaboration and BPMN-style process collaboration. This article explores why state systems can only have one active state at a time, while process systems can have multiple active tasks in parallel.
One of the most common sources of confusion when comparing state-based collaboration to process/BPMN-based collaboration is this:
State systems can only have one active state at a time.
Process systems can have multiple active tasks in parallel.
This difference is not just a design choice—it arises from two completely different underlying models. Once understood, the distinction makes the strengths and limits of each approach very clear.
1. States Are About Truth. Processes Are About Work.
State = the single correct condition of the item at this moment
Only one truth can be correct at a time.
Examples:
- A pull request cannot be both Open and Merged.
- An order cannot be Shipped and Delivered.
- A document cannot be Draft and Approved.
A state describes a mutually exclusive reality.
Process tasks = work being performed on the item
Multiple tasks can legitimately be active in parallel.
Examples:
- Legal review and financial review can run simultaneously.
- Two departments can review different parts of the same application.
- Multiple people can work independently on different subtasks.
Work can be parallel. Truth cannot.
This is the fundamental difference.
2. State Systems Are Based on Finite State Machines (FSMs)
In a state-based system:
- There is one and only one active state.
- Transitions move the item from one state to another.
- Collaboration happens through the shared state, not through tasks.
Finite state machines have exactly one active node ("the token") at any point.
This is why:
- Kanban boards model items with mutually exclusive states
- Pull requests and issues have a single canonical status
- Lifecycle flows are simple and unambiguous
The core property is one source of truth.
3. Process Systems Are Based on Petri Nets (BPMN)
BPMN and workflow engines are based on Petri nets.
Petri nets allow:
- multiple tokens
- in multiple nodes
- at the same time
This enables:
- parallel reviews
- concurrent activities
- split-and-join structures
- long-running multistep flows
Both tasks are active simultaneously.
Process engines are designed to support parallel work, not singular truth.
A BPMN diagram showing parallel task execution. After the initial task, the workflow splits into four parallel tasks that execute simultaneously, then joins before the final task.
4. Why This Difference Matters for Collaboration
State-Based Collaboration
Collaboration is structured around where the work item is in its lifecycle.
Benefits include:
- clear ownership
- deterministic next steps
- simple governance
- easy auditability
- low ambiguity
Everyone sees: "This is where we are. This is the next allowed transition."
Process-Based Collaboration
Collaboration is structured around what tasks are currently happening.
Benefits include:
- support for simultaneous responsibilities
- richer, more flexible flows
- ability to model real-world parallelism
But also:
- higher complexity
- more coordination overhead
- potential for races or deadlocks
- more logic required to join paths back together
Processes are powerful—but they are complex because real work is complex.
5. Why You Can't Add Parallel Tasks to a State System
If you add multiple parallel tasks, you have fundamentally changed the model:
- You no longer have a single state.
- You no longer have a finite state machine.
- You no longer have a single, authoritative source of truth.
- You've turned the system into a Petri-net-style workflow engine.
FSMs and BPMN engines are not interchangeable. They solve different problems.
6. The Deep Technical Reason
Formal distinction
Finite State Machine (FSM)
- Exactly 1 token
- Exactly 1 active state
Petri Net (BPMN)
- Multiple tokens
- Many active tasks/stages concurrently
This single difference leads to different tradeoffs:
Comparison table
| Aspect | State Machine | BPMN / Petri Net |
|---|---|---|
| Active nodes | 1 | Many |
| Concurrency | No | Yes |
| Ownership model | One at a time | Distributed |
| Primary concept | Lifecycle truth | Ongoing work |
| Complexity | Low | High |
| Coordination style | Sequential | Parallel |
They are different tools for different kinds of collaboration.
Conclusion
State systems and process systems are built on two very different foundations:
- State systems represent the truth about where an item is in its lifecycle. They allow exactly one active state and support clear, predictable collaboration.
- Process systems represent the work being performed. They allow multiple tasks to run in parallel and support complex workflows with concurrent responsibilities.
Both are valid. They simply answer different questions:
- If you need clarity, determinism, and a single source of truth → State-based collaboration
- If you need rich parallelism and multi-party workflows → Process/BPMN systems
Understanding this difference is essential for designing robust collaboration models.
Related content
This article connects to:
- State Machine Design Pattern - Learn how state machines work in collaborative systems
- Framework overview - Understand how states and transitions work in the framework
Explore more articles
This article is part of a series exploring collaboration patterns and practices. Check out other articles or dive into the framework components.