Test a workflow before publishing
What this achieves
Section titled “What this achieves”Validation tells you whether a route could run at all. Simulation shows you the path a request would actually take and who would be asked, without creating a task or writing anything.
Required role: Administrator.
Before you start
Section titled “Before you start”Simulation runs against a saved version, so save the draft first. Until it is saved, the panel tells you to save the version to enable simulation.
- Open the workflow’s draft version in the designer.
- Select Validate.
- Read Validation Results. Use Go to on an issue to jump straight to the step it concerns.
- Fix the errors and validate again until it reports no issues.
- Select Simulate.
- On Single Pass, check the Context (JSON) — the sample data the run uses — and select Run.
- Read the path it took on the timeline, then select Exit Simulation.
What validation checks
Section titled “What validation checks”Issues are grouped so you can tell a broken route from an incomplete one.
| Option | Description |
|---|---|
| Structural | The shape of the diagram — steps that lead nowhere, branches with nothing to merge them, missing start or end. |
| Edge Conditions | The tests on the lines, including more than one default line out of a step. |
| SLA | Problems with the deadlines set on steps. |
| Approver | Problems with who a step would ask. |
Errors and warnings are not the same thing. Errors stop a publish and the panel counts them; warnings do not, and a route can be published with them outstanding. Read them anyway — a warning is usually the thing that will surprise you in production.
Validating saves your unsaved changes first, so what is checked is what is stored.
The three ways to simulate
Section titled “The three ways to simulate”| Option | Description |
|---|---|
| Single Pass | Runs the whole route in one go and shows the path it took. The fastest way to check a branch goes where you meant. |
| Interactive | Walks the route one step at a time. At each approval step you choose approved or rejected, so you can follow a rejection path deliberately. |
| History | Previous runs against this version, for comparing what changed after an edit. |
A run reports one of four results: OK, Dead End, Cycle Detected, or Error. The last three are the ones simulation exists to find — a dead end is a request that would stop with nobody asked, and a cycle is a route that would loop.
Example: Priya Raman simulates HC Corp’s promotion route with a senior-grade employee in the context and sees it take the Finance path to Daniel Okonkwo. She runs it again with a junior grade and sees the manager path. Two runs confirm the branch, before a single real request has been raised.
Nothing is written
Section titled “Nothing is written”A simulation creates no tasks, notifies nobody, and changes no records. It is safe to run against a live workflow’s draft version as often as you like.
That also means it proves the path, not the outcome. Simulation shows that a step would ask Daniel Okonkwo; it does not tell you whether he would approve.
What happens next
Section titled “What happens next”A route that validates clean and simulates the way you expect is ready to publish. Publishing runs the same validation again and refuses if anything has broken since — so an error at publish time means something changed after your last check, not that validation was wrong.
Related
Section titled “Related”© 2025-2026 Humavera Documentation - BPilot Ltd. All Rights Reserved