Skip to content

Testing and runs

Every flow can be tried before it does anything. Once it is on, every run has a timeline that says what happened, who each step acted as, and what is left to do.

Press Test in the editor and choose a record from the Dry run tab: a recent ticket from your desk, or a real person from your roster. The drawer says Nothing will change, and it means it: no ticket, account or message is touched.

Plugboard reads what each step needs and shows, on the spine, what it would do: the before and after of each change, where it would wait, who it would ask for a go-ahead, and where it would stop and why. You see each condition as Met or Not met, and the verdict: it would start, it would not start, or it would wait for the person’s details first.

  • A dry run reads the record through your own campus and desk access, so you can only test on what you could open.
  • Conditions in words and Decide steps use answers already recorded for that record, or the question’s words to look for. A dry run never spends an AI decision.
  • The dry run picks tickets and people. Repair flows, and flows about other records or about no one record (schedules, events, other apps), are tested by publishing them as Watching instead.

The Backtest tab (or See which recent tickets these match under the conditions) checks the flow’s conditions against your 500 most recent tickets, repairs or people, and lists up to 25 that would have started it. Conditions in words are checked with their words to look for, not asked of AI. For “changes”, “goes late” and “untouched” triggers, each ticket is checked as it is today, not as it was when it changed.

Publish as Watching puts a flow on live work without letting it do anything. Every real ticket, repair or person that would start it gets a run that records what each step would have done and changes nothing. Conditions in words use their words to look for. Watch a flow for a week, then publish it on.

The Checked tab on Flows lists, for 14 days, every record a flow checked and did not start on, with the reason (“Rule said no”). If one should have run, press Should have run: the run starts, and any condition in words on it is labelled as a miss, which teaches the question (see decision models). The flow must be on.

The Runs tab, on Flows and on each flow, lists runs with their record, status, when they started and the step they are on. Needs attention lists the runs waiting on a person because a step failed, with a count on the tab.

Status Meaning
Checking Waiting for AI to answer a condition in words
Proposed Waiting for a person to confirm it should start
Waiting Waiting for a time, a date, an approval, a go-ahead, a task or missing details
Running Working through its steps
Needs attention A step failed and the run is paused for a person
Done Finished
Stopped Ended by a Stop step or by a person
Didn’t run Checked and not started (shown on the Checked list)

Open a run to see it at /flows/runs/.... The header shows the flow and its version, the record (linked), the status and when it started, with Stop run and, for runs that opened one, Open case ticket. A case ticket holds a run’s approvals, tasks and hand-offs; it opens the first time someone is asked for something.

Below, the run uses the same spine as the editor. Each card shows its state (done, waiting, needs attention with the reason, skipped, undone, not reached), when it ran and who it acted as (“Acted as the flow, within Jo’s access”, or “Acted as Sam, with their access”). Open a card for Inputs, Output and Before and after. In a branch, the lane taken is highlighted.

Each card offers only what you are allowed to do.

  • Retry a failed step, after fixing the cause.
  • Skip a step, with a reason that stays on the run and in the audit log. The run carries on from the next step.
  • Stop run, with a reason.
  • Answer. A task’s form, the details a person flow is waiting for, or the answer to a Decide step that was not sure (“Choose the answer for this record”), with Use this answer.
  • Give the go-ahead or Decline on a go-ahead card. The card leads with what will change and lists the steps it covers. Declining needs a reason and nothing it covers runs.
  • Was this right? on a Decide card, to confirm or correct the AI’s answer.
  • Undo a step that can be undone, or Undo this run from the run’s menu. Undo needs step-up and reverses each step in turn; any step that needs a go-ahead waits for one. Nothing is deleted: undoing a created account turns it off.

A run that fails partway stops at the failed step as Needs attention, and the timeline says exactly what is true: which steps are done and why this one failed. It never unwinds by itself. A half-finished leaver or joiner leaves the person with less access, which is the safe state.

From there you retry, skip, hand the work to a person, or undo the run. Transient failures (a timeout, a busy service) are tried again after 1, 5 and 30 minutes when the step is set to Try again, then pause and is safe to repeat; messages are not.

A step that was interrupted while it was being sent is marked as an unknown outcome after 15 minutes (“check what happened before trying again”) and is never retried on its own.

Tickets, repairs and people have a Flows section, for people with flow.view while the Automation module is on.

  • Tickets show the runs on that ticket as chips with their status, any flows offered on it, and Run a flow.
  • Repairs show the flows offered on the repair and the runs about it.
  • People show their joiner, mover and leaver runs with what happens next, and Run a flow.

Run a flow shows the flow’s form, then What will happen, worked out from a dry run, including any step that will ask someone else for a go-ahead. Steps you can do run as you; anything else asks for a go-ahead. Offers have their own card with Do it now, Request approval and Dismiss; see offers.