Loading

Simulating a Workflow

Simulate runs a workflow on one real record and shows what a real run would do, without saving anything or sending anything. You see the path it takes, the fields it would change, every message and request it would send, and the values it ends with. It is the safe way to test every branch before you publish.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — open a workflow and press Test…; Simulate is at the foot of the dialog

Running a simulation

  1. Press Test….
  2. On a published workflow, choose under What to test: "Your draft, with the unpublished changes" or "The live version".
  3. Check the Datastore, type part of the record's name or its number in Find the record, and pick it under Record.
  4. Optionally open Sample data and decisions (below).
  5. Press Simulate. The report appears under the form and the path is drawn on the canvas.

Sample data and decisions

  • Started by: Someone starting it by hand, The record being added, or The record being changed.
  • Field values for the simulation: press Add a field value to lay a different value over the record for this simulation only (a bigger amount, another status). Nothing is saved.
  • How the decisions go: nobody is asked in a simulation, so say how each approval, verification, signature or AI step is answered (approved or rejected, signed or not signed, and so on).
  • Pin this record, these values and decisions to the workflow: the next simulation starts from them. A Pinned badge shows when a sample is pinned; Unpin the sample removes it. Pinning needs the editor role or above.

Reading the report

  • Changes to this record: each field, its value now and after the run.
  • Messages and requests it would send: every e-mail, text message, WhatsApp, letter, notification, webhook call, approval request, identity check, signature request, AI question, extension step and PHP function, with its recipients and wording filled in from the record.
  • Every change it would make: each record it would add, change or delete, in any datastore.
  • Values the run ended with: variables and the results of look-ups and earlier steps.

Below the report are the steps taken and the port each left by, as in a real run's history.

What runs and what is only described

Steps that only work inside the platform really run, inside a database transaction that is rolled back at the end: Update record, Set status, Create record, Convert record, Look up, Set variables, Conditions, For each, Parallel and Join, Sub-workflow, in-app notifications, SLA timers and the workflow library's functions. Steps that reach outside, or wait for someone, are described instead: e-mail, SMS, WhatsApp, letter, notifications by e-mail or push, webhooks, approvals, verifications, signatures, waits, AI steps, extension steps and custom PHP functions. A described step leaves by the port a real one would, or by the decision you chose.

If a step that does run tries to send a message itself (an ERP status change that e-mails someone, say), the send is stopped and the report shows "Stopped in the simulation".

What goes wrong

  • "Simulation - some changes were NOT undone": a step committed its changes part way through. Check the record before relying on it and tell an architect.
  • Values hidden in the report: when you are not an architect, what other records hold and the wording of each message is shown to architects only, because a simulation runs with the platform's rights.
  • Simulate refuses to run for an organisation kept in its own separate database on the platform's server; this is not supported yet, and the dialog says so.
  • Test… is missing: Viewer is the only role that cannot simulate.

Run for real

Run for real… sits beside Simulate. It asks "Run it for real?" and, once confirmed, runs the steps for real: data changes and messages go out. The run is marked as a test. Testing the draft of a published workflow runs a hidden copy of the draft, so the live version is untouched and the run is badged "draft test". Use it last, on records and addresses you control.

Worked example

An architect has drawn a purchase order approval with a threshold of 5,000. They pick a real order worth 1,200 and simulate: the report shows the order would be issued and one e-mail sent to the buyer. They add a field value of 8,000 for the amount and set the approval to Rejected under How the decisions go: the report now shows an approval request to the Approvers group, a cancellation and a notification to the buyer with the rejection. They pin that sample so the next change can be checked the same way, then publish.

Recommendations

  • Simulate every branch, using field values and decisions to reach each one.
  • Read the Messages section word for word: it is what your customers would receive.
  • Pin a sample for workflows you change often.
  • Simulate the draft before publishing, and the live version after.