Loading

Building and Testing

This is the sequence for building a workflow that works first time: draw it in a draft, let Validate check it, simulate it on real records, and only then publish. The draft can be tested as often as you like without anything starting it for real.

Where to find it

Architect Panel → Automation:

  • Workflow Builder — New workflow, New from template…, or open an existing workflow
  • Workflow Run History — the runs your tests produced

Build in this order

  1. Write the process down in a few sentences, including what happens when somebody says no.
  2. Create the workflow with New workflow (or New from template…). Fill in Name, Works on records in and Starts, then press Save draft (Ctrl+S).
  3. Add the Trigger. An empty canvas offers an Add a Trigger button.
  4. Draw the ordinary path end to end, then the exceptions. Connect a step by dragging from a port on one card to the next card.
  5. Press Validate and work through the Problems tab until there are no errors.
  6. Simulate on real records, once per branch.
  7. Publish, then watch the first runs.

Working on the canvas

  • Tidy up lays the steps out left to right in the order they run.
  • Map shows an overview of a large workflow; Fit brings it all into view.
  • Shift+click selects several steps; Ctrl+C and Ctrl+V copy them, with the lines between them, into this workflow or another one. The Trigger is never copied.
  • Ctrl+D duplicates the open step, Delete removes the selection, Ctrl+Z and Ctrl+Y undo and redo. Press ? for the full list.
  • Note steps add sticky notes for the next person to read the workflow.
  • Fields that accept values from the record have a { } button that opens Insert a value; see Placeholders and Variables.

Validate and the Problems tab

Validate checks the draft against the engine's rules and lists each issue under Problems, as an error or a warning. Steps with issues are flagged on the canvas, and selecting one shows "From the last check" in its panel. Errors block publishing; warnings do not. Typical messages:

  • "Add a Trigger - every workflow starts at one." and "Connect the Trigger to the first step."
  • "This step can never be reached. Connect it into the flow, or delete it."
  • "The 'false' path is not connected, so the run ends here…" (a warning).
  • "Choose a template, or write a subject and body." on an E-mail step.
  • "The 'Workflow Resume' task is disabled, so Wait steps never end."

The Test dialog

Test… opens one dialog with two ways to try the workflow on a record:

  • What to test: on a published workflow, choose "Your draft, with the unpublished changes" or "The live version". Testing the draft does not publish it.
  • Datastore, Find the record and Record: the newest 20 records are listed; type a name or record number to find any other.
  • Simulate: runs the workflow inside a transaction that is thrown away, so nothing is saved and nothing is sent, and reports what would have happened. See Simulating a Workflow.
  • Run for real…: asks you to confirm, then runs the steps for real: data changes and e-mails and messages go out. The run is marked as a test.

The result shows each step and the way it left, and Show on canvas draws the path on the drawing, numbering the steps in the order the run reached them and dimming those it never reached. The Recent runs tab under the canvas lists this workflow's latest runs, with a "test" badge on test runs and a "draft test" badge on test runs of the unpublished draft.

What goes wrong

  • Publish… is refused with "Fix N problems before publishing". The errors are listed in the dialog and under Problems.
  • A test run e-mailed a real customer. Run for real sends for real. Simulate first, and run for real only on records whose addresses you control.
  • Test… is missing. Your role on the workflow is Viewer, which cannot simulate or test.

Worked example

A finance team builds an invoice query workflow. They draw the ordinary path, press Validate, and fix two errors (an E-mail step with no recipient and an unconnected Trigger). They simulate on three real invoices: one under the threshold, one over it, one with the approval answered "rejected" under How the decisions go. Each report shows the right path and the e-mails that would go out. They publish version 1, then open Workflow Run History at the end of the day to read the real runs.

Recommendations

  • Save little and often: the draft is safe to save at any time once published, because only Publish changes what runs.
  • Simulate before you ever run for real.
  • Test every branch, including every rejection route.
  • Read Problems warnings, not only errors.
  • Review the first day's runs after publishing.