Nested states

States do not have to be a flat list. A state can have substates, and a substate can have its own — a tree up to three levels deep. That is how one flow holds modes within modes without turning into a tangle of unrelated flags.

support                     ← top-level state
├── billing                 ← substate
│   ├── refund_requested    ← third level
│   └── invoice_copy
└── technical
    └── outage_reported

Limits

On the canvas

Substates are drawn inside their parent's card rather than as separate nodes, so the graph shows the structure at a glance: open the parent to see what it contains.

Peers are per parent

A substate's peers are the other substates of the same parent — not every state in the flow. refund_requested and invoice_copy are peers; refund_requested and outage_reported are not. Activation patterns work within that peer set, so sub-modes of billing never interfere with sub-modes of technical.

Cascades

A substate can take a value automatically whenever its parent changes:

• When the parent activates — for example, reset billing.refund_requested to a known value every time the conversation enters billing.
• When the parent deactivates — for example, put the substate back to its default value whenever the conversation leaves billing.

Cascades are what keep a sub-mode from carrying stale values into the next time its parent is entered.

Removing a parent

Removing a state removes its substates with it, and anything that was gated on them stops being gated. Check what depends on a branch of the tree before deleting it.