What is a scenario-aware process?

Put plainly: a real operation is never one straight line, so a real process cannot be one either. A scenario-aware process holds every variant of the work inside a single governed model. Feed it the conditions of the case in front of you and it resolves to one route: the steps that apply, the people who own them, the checks that have to pass, and the sign-off that has to happen. Nothing on the screen belongs to a different situation. The route bends to the case, and the case is described as data, not chosen from a menu by a human who has to remember which diagram is current.

Why the alternatives fall short

There are two common ways teams try to handle variation, and both break in the same place.

Ten diagrams, one per variant. You draw the standard flow, then the dangerous-goods flow, then the pharma flow, then the missed-connection flow, and so on. It looks thorough. The problem is that the ten diagrams share most of their steps, and the shared part drifts apart the moment you copy it. Change the acceptance check once and you have to hand-edit it in ten places. Miss one and you have a live contradiction, which is exactly the kind of thing an auditor finds and a new hire follows off a cliff. The library grows, nobody trusts which file is current, and the variation you were trying to capture becomes the reason the whole set goes stale.

One diagram with show-hide logic. The other move is a single flow with conditional branches drawn on it, or a form that reveals fields when you tick a box. This is closer to right, but the logic is buried inside a picture or a UI. It is not owned, not versioned, and not legible on its own. You cannot ask it "what does this process do for a dangerous-goods shipment that is also temperature-controlled?" and get a governed answer. The branch is decoration on a drawing, not a decision you can stand behind.

Both fall short for the same reason: they treat the exceptions as an afterthought bolted onto a happy path, when the exceptions are the operation. In regulated logistics the standard shipment is the rare one.

The properties that make a process scenario-aware

• One master process, not a collection. There is a single source that owns every variant. You never maintain parallel copies, so they cannot disagree.
• Conditions-as-data. The things that change the route (mode, commodity, temperature regime, customer, lane, risk flag) are structured attributes, not prose. The process reads them and resolves. This is what lets the same logic answer a human, a form, and an AI agent identically.
• Resolution, not navigation. The person doing the work does not navigate a maze of branches. They state the case and receive the route. The complexity lives in the model, not on their desk.
• Governed, so it stays true. Every version, comment, and approval is on the record. When a route changes, it changes under sign-off, with an audit trail, so the process you followed last month is provable and the one you follow today is current.
• Composable exceptions. A shipment that is both dangerous goods and temperature-controlled resolves to the combined route, not to whichever single diagram someone remembered to open. The conditions stack.

This is FLOW's moat, and it is worth being precise about why. Anyone can draw branches. The hard, valuable thing is holding one governed master process that resolves correctly across every combination of conditions and keeps doing so as the operation changes. That is the difference between a picture of a decision and the decision itself. It is also what makes the process readable by an AI agent over an API: an agent cannot follow a Visio file or a paragraph of prose, but it can query a process whose conditions are data and get the same resolved route a person would.

When it matters, and when it does not

Scenario awareness is not a virtue in the abstract. It earns its place when exceptions are the norm: when who signs off, which checks apply, and which steps run all depend on the case, and when getting the wrong route costs you a shipment, a customer, or an audit finding. That describes most of regulated logistics and a lot of regulated operations generally.

It is genuinely overkill when the process has one honest path. If there are no meaningful variants and no branch that changes ownership or sign-off, a plain checklist is the right tool and a scenario-aware model is more than you need. The test is simple: count the ways the work legitimately differs by situation. If the answer is "one," draw a checklist. If the answer is "we lost track," you have been living the ten-diagrams problem, and one master process that resolves per scenario is the way out.

Scenario awareness is one of the properties that separates a living process from a dead document. For the layer that holds it, see the process system of record, and for why documents keep dying even when you keep them fresh, see living process documentation. To see the scenario engine resolve a real route, look at the product, or read how this compares to drawing tools in FLOW vs Lucidchart.

Common questions