Scenarios
A scenario describes one situation you want your system to play out: where a request starts, what data it carries, and how far the run may go. The diagram is the map; the scenario is the trip.
What a scenario is
A scenario never changes your diagram. It just answers three questions: where does the run start (which component and output port), what data is involved (the request payload and any records already sitting in databases, caches, or queues), and when should the run stop (limits on events and time). Because every scenario also has a seed, the same scenario always produces exactly the same run — you can replay it, share it, and compare it.
Create a scenario
- In the editor, open the Scenario tab in the workbench dock at the bottom of the screen.
- Press New scenario, or Clone variant to start from a copy of the current one. The Active scenario dropdown switches between drafts.
- Fill in the form — it walks you through 01 Setup, 02 Data, and 03 Execution limits. Changes autosave as you type.
The scenario form at a glance
01 Setup — a name and description, an optional journey family for grouping variants, and the start component and start output port where the run begins (an Actor is the usual starting point).
02 Data — the input payload (the JSON the first request carries) and state fixtures: records you want already present in a database, cache, queue, or external dependency before the run starts.
03 Execution limits — a seed for repeatable runs, plus max events and max time so a run always finishes safely.
The compatibility panel next to the form tells you if the scenario still matches the diagram — for example after you delete the component a scenario started from. A scenario must be saved and compatible before it can run.
Run it
Switch to the Run tab and press Run scenario. The status moves through Compiling and Running to Completed — or Guarded if a limit stopped it, Cancelled if you pressed Stop run, or Failed with an explanation of what went wrong. A finished run reports how many events it produced and how much virtual time passed, and you can rerun it any time with Retry scenario.
Runs demonstrate configured behavior and ordering. Durations and outcomes are illustrative — don’t use them to predict production capacity, latency, or cost.
Replay it, step by step
After a run, switch to Simulate mode to replay it without changing anything. The playback controls work like a video player: play and pause, step one event or one stage at a time in either direction, scrub to any position, and change the speed. Watch the canvas while it plays — the active connection animates, and the current step is described right on screen. The events themselves appear in the Timeline and Transcript — see Events for how to read them.
Compare variants with journeys
Give related scenarios the same journey family — say, “Checkout” with a happy-path variant and a payment-fails variant. The Journey matrix panel can then run several variants side by side and show each one’s status, path, and outcome in a table.
On the canvas, the Journey route focus toolbar highlights routes: All topology shows the whole diagram, Potential route highlights the path the selected scenario could take, and Actual route highlights the path the latest run really took — everything else dims so the story stands out.
Add scenarios to a checkpoint
A draft is where you keep working; a checkpoint is a saved review point that does not change underneath you. Select Checkpoint in the editor command bar, add an optional message, choose the compatible scenario drafts to include, and create the checkpoint.
You can make a diagram-only checkpoint when there are no scenarios. A scenario with a problem cannot be included until it is repaired. Creating a checkpoint never replaces your working draft.
See Drafts and checkpoints for the complete explanation and step-by-step instructions.