Workflow Builder

Drawing automation on a canvas: triggers, the 28 kinds of step, branching, waits, versions, simulation, who can use a workflow, and the run history.

The Workflow Builder

The Workflow Builder is where you draw a process as steps on a canvas: what starts it, what each step does, and which way a run goes after each decision. Use it when something should happen to a record over time, in a set order, with branches, waits or a person's approval along the way.

Where to find it

Architect Panel → Automation:

Workflow Builder — the library of workflows and the canvas editor
Workflow Run History — every run of every workflow, its steps and why any failed
Approvals Inbox — the approval steps waiting for your decision

Admin Panel → Processes:

Approvals Inbox — the same inbox for back-office users, with buttons to the workflows they have a role on

The library

The Workflow Builder opens on a list of workflows. Six tiles summarise them: Workflows, Active, Drafts, Unpublished changes, Runs waiting (approvals, waits, signatures) and Failed runs (last 30 days).

Filters: Search (name, datastore or description), Status (Active, Draft, Disabled, Has unpublished changes), Starts (By hand, On a record change, On a schedule) and Show deleted.
Columns: Name, Starts, Works on, Status, Last run, Waiting, Failed (30 days) and Last saved. Click a name to open it; click a failed count to see those runs.
Buttons: Import, New from template… and New workflow. Each row also has Runs, Duplicate and Delete.

An architect sees every workflow. Someone given a role on a workflow sees only those, with a "Your role" badge; see Who Can Use a Workflow.

The editor

Settings sit above the canvas: Name, Works on records in (the target datastore), Starts, and the trigger details, plus a Description.
Steps on the left is the palette. Drag a step onto the canvas, or select it and press Enter. Find a step filters the list.
The canvas holds the steps and the lines between their ports. Its toolbar has undo and redo, zoom, Fit, Tidy up, Map, copy and paste, and the keyboard shortcuts list.
The step panel opens on the right when you select a step: its Step name, its settings and a short "how this step works".
Problems and Recent runs are tabs under the canvas.

The header carries Save draft, Validate, Publish…, Disable (or Activate), Test… and More, which holds Versions…, Run history, Who can use it…, Duplicate workflow, Export as JSON, Import from JSON… and Delete workflow….

How a workflow lives

Draft: a new workflow is a draft. Nothing starts it on its own, but you can validate it, simulate it and test it.
Active: Publish makes the saved draft version 1 (then 2, 3…) and turns the workflow on. Later saves change only the draft until you publish again.
Disabled: nothing new starts it; runs already under way carry on.

Every run belongs to one record (a scheduled run may have none) and records each step it took, the way each step left, and why it failed if it did. See Versions and Publishing and The Run History.

When a workflow is the right tool

A process on one record over time: acknowledge, wait, check, escalate, ask for approval.
Anything with a person in it: an approval, an identity check or a signature.
Work on a schedule: a daily sweep that finds overdue records and acts on each.
Checking or shaping a save: a workflow that runs before a record is saved can set fields or refuse the save.

A recurring programme of messages to many people is a journey, whose steps are themselves workflow steps. A purely technical job is a task.

What goes wrong

A workflow with a Wait never moves on. The Workflow Resume task is off. The Wait step's panel and Workflow Run History both say so.
A scheduled workflow never starts. The Workflow Scheduler task is off, or the workflow was never published.
Someone cannot open the builder. They are not an architect and hold no role on any workflow; the page says so.

Worked example

A housing association wants every new repair request acknowledged and chased. An architect chooses New workflow, names it "Repair acknowledgement", sets Works on records in to the repairs datastore and Starts to When a record changes, A record is added. They add an E-mail step, an SLA timer of 2 working days, a Wait until that deadline and a Condition that checks whether the repair is still open, with a Notify step on its Yes path. Validate shows no problems, Simulate on a real repair shows the e-mail that would be sent, and Publish makes version 1 live.

Recommendations

Start from a template where one is close; see Workflow Templates.
Simulate before you publish: it changes nothing and sends nothing.
Write a Description saying who relies on the workflow.
Give a process owner a role so they can see its runs without being an architect.
Check the two workflow tasks are on before relying on waits or schedules.

Triggers

A workflow starts in one of three ways: by hand, when a record changes, or on a schedule. You choose which in the settings above the canvas, and refine it on the Trigger step, the one step every workflow begins with.

Where to find it

Architect Panel → Automation:

Workflow Builder — open a workflow; the Starts setting is above the canvas and the Trigger step is the first card

The three ways to start

By hand: started from the builder's Test dialog, from a record's Processes pane (Run a workflow), by a journey, or by an inbound-message route (see Receiving Messages).
When a record changes: a record of the target datastore is added, changed or deleted.
On a schedule: every so many minutes, hours, days or weeks, with or without records to work through.

Only a published, active workflow is started by a record change or a schedule. A draft never is.

Starting when a record changes

Set Works on records in to the datastore.
Set Starts to When a record changes, and Record change to A record is added, A record is changed or A record is deleted.
Set Runs:
- After the record is saved: the usual choice. The workflow reacts to a settled change and may wait, ask for approval and send messages.
- Before it is saved (can check or change it): the workflow runs during the save. It can set the record's fields, and an End step marked Failed refuses the save, showing its message to the person saving. It cannot wait.
Select the Trigger step and, if you need them, fill in its start conditions (below).
Save, then Publish. Saving or publishing an event workflow makes sure the datastore passes its record changes to the workflow engine (it creates a table rule for the datastore when none exists), and the note under the settings says whether this is in place. Nothing starts the workflow until it is published.

Start conditions on the Trigger step

Start only when: rules that must all hold for the record as saved. Any other save starts nothing, so Run History shows only the runs that matter. Values may use {{today}}, {{today-30}} and {{now}}.
Not while a run of this workflow is still going on the same record: a second save while the first run waits (for an approval, say) does not start a second run.

Use these rather than a Condition straight after the Trigger: a Condition still creates a run for every save, and the history fills with runs that stopped at their first check.

Starting on a schedule

Set Starts to On a schedule and Runs every to a number and a unit (minutes, hours, days or weeks).
Select the Trigger step and choose under Each time it runs:
- Run once, with no particular record.
- Start a separate run for each matching record: each record gets its own run, history, waits and approvals. A record whose previous run is still going is skipped.
- Work through the matching records in one run: a For each step after the Trigger repeats its path for every record.
For the last two, add rules under Only records where (none means every record) and set At most this many records each time (500 when left blank, 5,000 at most).
Publish. Once it is active, the Trigger step shows Last ran and Runs next.

Two buttons sit under the schedule. Run on the next tick brings the next run forward. Run this schedule now… runs this workflow's schedule immediately, for real; it needs the owner role or an architect.

The Workflow Scheduler task

Scheduled workflows are started by the task Workflow Scheduler (scheduled workflows). It is installed switched off and in preview mode, and checks every 5 minutes, so no schedule runs more often than that. An architect turns it on from the Tasks screen; the help under Runs every says when it is off and offers Open Tasks. See Tasks.

What goes wrong

"Not wired yet" in Problems: no table rule passes the datastore's changes to the engine. Save, publish or activate the workflow to wire it.
A workflow re-triggers itself. An update workflow that updates its own record starts again. Narrow it with Start only when, or tick Not while a run is still going.
Thousands of runs after an import. Every added record starts a run. Add start conditions, or disable the workflow during the import.
A scheduled run has no record. With Run once, steps that read the record have nothing to read; choose one of the record options.

Worked example

A purchasing team wants approval to start only when an order is sent for approval. The workflow works on purchase orders, starts When a record changes, A record is changed, After the record is saved. On the Trigger step, Start only when says the status equals Pending Approval, and Not while a run is still going is ticked. Saving a draft order starts nothing; sending it for approval starts one run, and saving it again while the approver decides starts no second request.

Recommendations

Use After unless you need to change or refuse the save itself.
Put start conditions on the Trigger rather than in a first Condition.
Tick Not while a run is still going on any workflow that waits for a person.
Turn the Workflow Scheduler task on before relying on a schedule.
Prefer one run per record for scheduled work that waits or asks for approval.

Node Types

The Steps palette offers every kind of step a workflow can contain, in eight groups. This page lists each one, what it does and the ports it leaves by, so you can pick the right step before reading its own article.

Where to find it

Architect Panel → Automation:

Workflow Builder — open a workflow; the Steps palette is on the left of the canvas

Flow

Trigger: where every run starts. Exactly one per workflow. See Triggers.
Condition: checks the record, or a value from an earlier step, and goes down Yes or No.
Parallel: runs every step connected to its Next port.
Join: waits for parallel branches to arrive, then carries on once.
For each: repeats its Each row path for every matching row, then leaves by When done.
Sub-workflow: runs another active workflow on this or a linked record.
End: finishes the whole run as Done or Failed, with a message.

Records

Update record: sets fields on this record or another one.
Set status: sets one status field and notes the change in the record's activity; on an ERP document it makes the document's own declared move.
Create record: adds a record to any datastore and links it to this one.
Convert record: copies fields of this record into a new record elsewhere and links the two.
Look up: finds the first matching record and goes down Found or Not found.
Set variables: works out values once and names them for later steps.

Timing

Wait: pauses the run for a length of time, or until a date.
SLA timer: works out a due date, optionally in working time, stores it on a record and carries straight on.

Messages

E-mail, SMS, WhatsApp and Letter: send through the chosen account.
Notify: tells a person or a group in the app (their in-tray), by e-mail or by push notification.

People

Approval: waits for a named person, or anyone in a group or team, and goes down Approved or Rejected.
Verification: asks a person to prove who they are; Verified or Rejected.
Signature: sends a document for e-signature and waits; Signed or Not signed.

Other systems

Webhook: calls another system over HTTPS; Next or On error.
PHP function: calls one of the workflow library's functions or a function your installation declares.
Extension step: runs a published extension's code; Next or On error.

Only an architect may add or change these three steps. See Webhooks, Functions and Extension Steps.

AI decisions

AI decision: asks TypeSafe Jev to pick one option, or a level, from fields of the record; Sure or Needs a person.
AI check: asks TypeSafe Jev whether a statement is true of the record; Yes, No or Needs a person.

This group is hidden when the AI module is off, and greyed out with a note when TypeSafe Jev is not set up. Both steps are described in AI Decision and AI Check Workflow Steps.

Notes

Note: a sticky note on the canvas for whoever reads the workflow next. It is saved with the drawing but never runs and is never connected.

A workflow drawn before the Condition step existed may show a Branch step. It behaves exactly like a Condition and is not offered in the palette.

Settings many steps share

Step name: shown on the canvas and in the run history. Name steps for what they mean, such as "Over the threshold?".
If this step fails, carry on with the next one: on record steps, SLA timer, Notify, PHP function, Sub-workflow, For each and Extension step. Off, a failure stops the run and marks it Failed.
Carry on if it cannot be sent: the same idea on E-mail, SMS, WhatsApp, Letter and Webhook.
A person may skip this step while it is waiting: on Wait, Approval, Verification and Signature. Skipping needs a reason, which is recorded.

How ports route a run

A step with one way out follows the line drawn from it.
A step with two or three ways out follows only the line from the port it came out of. A rejected approval can never continue down the Approved path.
A port with nothing connected ends the run there when the step comes out that way. Validate warns about it.
Several lines from one port are followed only from a Parallel step; any other step follows the first, and Validate warns.

Worked example

A complaints process uses Trigger, Set status (Acknowledged), E-mail, SLA timer (5 working days), Wait until that deadline, Condition ("Still open?"), Notify on Yes, Approval before closure, and Letter for the outcome. Each step is named for its meaning, so the run history reads as a story of the case.

Recommendations

Use Set status for statuses, so the change appears in the record's activity.
Connect every port of every two-way step, even if only to an End.
Use Notes to explain non-obvious choices on the canvas.
Prefer built-in steps over a PHP function where one exists.

Conditions and Branching

Branching is how a workflow treats records differently: a Condition sends a run down Yes or No, and a Parallel step sends it down several paths at once that a Join later brings back together. This page covers all three steps and the mistakes that leave runs ending quietly.

Where to find it

Architect Panel → Automation:

Workflow Builder — Condition, Parallel and Join are in the Flow group of the Steps palette

Setting up a Condition

Add a Condition step and connect the step before it into it.
Choose Go down 'yes' when: every condition is true, or any condition is true.
Add rows under Conditions. Each row has a Field, a Comparison and a Value.
Connect both the Yes and the No port to the next steps.
Give the step a name that asks the question, such as "Over 5,000?".

What a row can compare

Field: a field of the record, or a value from an earlier step, such as found.status after a Look up saved as "found".
Comparison: equals, does not equal, is more than, is less than, is at least, is at most, contains, does not contain, starts with, ends with, is one of (a, b, c), is none of (a, b, c), is empty, is not empty.
Value: a fixed value or a placeholder such as {{credit_limit}} or {{today-30}}. "Is one of" takes a comma-separated list. "Is empty" and "is not empty" take no value.

"Equals" and "does not equal" compare as text. "Is more than", "is less than", "is at least" and "is at most" compare as numbers when both sides are numbers, as dates when both sides are dates, and as text otherwise.

On ERP datastores many columns hold the ID of a pick-list entry. If you type a word such as approved, the engine looks it up among that list's codes and compares the ID. A word that is not one of the codes never matches, and Validate warns, listing the codes it accepts.

A Condition with no rows is an error: Validate refuses to let it be published.

Parallel and Join

Add a Parallel step and draw two or more lines from its Next port.
Build each branch as usual.
Where the branches should meet, add a Join and draw every branch into it.
Set the Join's Carry on when: every incoming branch has arrived, the first branch arrives, or 2, 3 or 4 branches have arrived.

The branches run one after another within the same run, not at the same instant. A branch that waits (for an approval or a Wait) parks the run, and the others carry on when it resumes. A branch that reaches the Join after it has already carried on ends quietly. "Every incoming branch" counts the lines drawn into the Join.

A common pattern asks for an approval on one branch and runs a Wait plus a reminder on the other, so a slow approver is chased without stopping the request.

What goes wrong

A run ends after a Condition with nothing else recorded. The port it took has no line. Validate warns: "The 'false' path is not connected, so the run ends here…". Connect it, even if only to an End step.
Only one branch runs. Several lines leave a port of a step that is not Parallel; only the first is followed. Add a Parallel step.
A Join never carries on. It expects every branch, and one branch ended or went another way. Use "the first branch arrives" or a number, or route that branch into the Join too.
A runaway loop. Steps that lead back on themselves with no Wait in between are stopped by the engine; Validate warns about the loop.
The wrong branch after a long wait. A Condition reads the record as it is now. A case closed during a three-day wait takes the branch for a closed case, which is usually what you want.

Testing branches

Use Test… then Simulate. Under Sample data and decisions, add field values to push the record down each branch in turn (a larger amount, another status) without changing the record. The path the simulation took is drawn on the canvas. See Simulating a Workflow.

Worked example

An expenses workflow first asks "Over 500?" (amount is more than 500). No goes straight to Set status Approved. Yes goes to a second Condition, "Travel?" (category is one of Rail, Air, Hotel), whose Yes path asks the travel manager and whose No path asks the line manager. Both paths end at their own End step. Two simulations with amounts of 200 and 800 confirm both routes before the workflow is published.

Recommendations

One question per Condition, so the run history shows which test sent a record where.
Connect both ports of every Condition.
Use Parallel only for real side-by-side work, and always close it with a Join.
Compare pick-list columns with their codes, and read the warning Validate gives when a word is not one.
Simulate every branch before publishing.

Waits and Timers

Two steps deal with time. A Wait pauses a run for a period or until a date. An SLA timer works out a deadline, optionally in working hours, and stores it on a record without pausing. Used together they give you "chase it if it is not done by the deadline".

Where to find it

Architect Panel → Automation:

Workflow Builder — Wait and SLA timer are in the Timing group of the Steps palette
Workflow Run History — shows waiting runs and warns when the resume task is off

Architect Panel → Data:

Business Hours Calendars — the working hours an SLA timer can count

The Wait step

Add a Wait step where the run should pause.
Either enter a length of time in Days, Hours and Minutes (decimals are allowed), or fill in Or until with a date and time (2026-12-31 09:00) or a placeholder holding one, such as {{due_date}}. If you give both, the date wins.
Tick A person may skip this step while it is waiting if somebody should be able to release the run early. A skip asks for a reason and records it.
Connect its Next port to what happens afterwards.

A waiting run holds nothing open. It records when it is due and stops; the task Workflow Resume (waits and SLA timers) carries it on. When the run wakes, later steps read the record afresh, so a change made during the wait is seen.

The SLA timer step

Add an SLA timer step.
Enter Time allowed (minutes): 480 for one eight-hour day, 2880 for two days.
Choose Count working time from: a business hours calendar, or "Every minute counts (no calendar)". With a calendar, evenings, weekends and closed days are not counted. See Business Hours Calendars.
Choose Stamp the deadline on: this record, or another record (a task a Create record step has just made, say), named by datastore and record ID.
Choose Store the due date in: a date field of that record.

The SLA timer does not pause the run and has a single Next port: it calculates the deadline, writes it, and the run carries straight on. Later steps can use the deadline as {{sla.step.due}}; pick it from the { } value list rather than typing it.

Chasing a deadline

SLA timer: set the deadline and store it on the record.
Wait: Or until the deadline, chosen from the value list.
Condition: is the record still open?
Yes: Update record (raise the priority) and Notify the escalation contact. No: End.

This is exactly what the SLA escalation template builds; see General Templates.

The Workflow Resume task must be on

The resume task is installed switched off and in preview mode, and runs every 5 minutes once on. Until an architect turns it on from the Tasks screen, no Wait ever ends. The Wait step's panel says when it is not installed, turned off or in preview mode, with an Open Tasks button, and Validate warns on any workflow with a Wait. Workflow Run History shows a banner too, and counts waiting runs that are past their time. See Tasks.

The same task clears runs whose process was killed: a run left Running with no progress for over 30 minutes is marked Failed, so it can be retried.

What goes wrong

Runs sit at Waiting long after their time. The resume task is off or in preview mode.
A before-save workflow with a Wait. A workflow that runs before the save cannot wait. Use an after-save workflow.
An approval that is never answered. The Approval step has no timeout of its own. Put a Parallel step in front of it, with the Approval on one branch and a Wait plus Notify reminder on the other.
The deadline lands on a weekend. No calendar was chosen, so every minute counted.

Testing with short waits

Simulate does not pause at a Wait; it describes it and carries on, so you see the whole path at once. For a real test run, set a few minutes first and the real duration before you publish.

Worked example

A support desk promises a first response within four working hours. Its workflow starts when a ticket is added, runs an SLA timer of 240 minutes against the office calendar, stamps the deadline in the ticket's Response due field, waits until {{sla.n2.due}}, then checks whether the ticket's status is still New. A ticket logged at 4pm on Friday gets a deadline of 12 noon on Monday, not 8pm on Friday.

Recommendations

Turn on the Workflow Resume task before publishing any workflow with a Wait.
Use a calendar for any deadline a person has to meet.
Re-check the record after a long wait with a Condition before acting.
Make waits for people skippable so an administrator can release a stuck run.
Chase approvals with a parallel reminder rather than leaving them open-ended.

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

Write the process down in a few sentences, including what happens when somebody says no.
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).
Add the Trigger. An empty canvas offers an Add a Trigger button.
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.
Press Validate and work through the Problems tab until there are no errors.
Simulate on real records, once per branch.
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.

The Run History

Every time a workflow runs, the platform records the run and each step it took: what the step was, the way it left (approved, rejected, yes, no), how long it took and why it failed if it did. Workflow Run History brings every run of every workflow into one screen, where you can find what is stuck or failed and put it right.

Where to find it

Architect Panel → Automation:

Workflow Run History — every run, its step timeline, and Cancel, Retry and Skip; the badge counts runs that failed in the last 7 days
Workflow Builder — More, then Run history, the Runs button on a row, and the Recent runs tab of one workflow

The summary tiles

Running, Waiting (with how many have waited over 7 days), Failed (last 7 days) and Finished (last 24 hours). Click a tile to filter the list to those runs.
Average run: how long finished runs took over the last 7 days. All runs: the total, and how many started in the last 24 hours.

A banner appears when the Workflow Resume task is off or in preview mode, when waiting runs are past their time, or when running runs have made no progress for over 30 minutes.

Finding a run

Filter by Search, Workflow, Status (Running, Waiting, Failed, Done, Cancelled, or In progress), Started from and Started to, Record in and Record number, and Test runs (Included, Left out, Only test runs).
Tick Hide runs that stopped at their first check to leave out runs whose only step after the start was a Condition that came out No.
Click a run to open the inspector beside the list.

Reading a run

Workflow and version, Record (by its name), with Processes on this record and All runs on this record. A scheduled run may have no record.
Status and the step it is at, Started, Finished, and Took (or Running for) with the number of steps.
Started by names the parent run when a Sub-workflow step started this one; Child runs lists the runs it started.
Why it failed, in words, on a failed run. A waiting run says what it waits on and until when.
Steps taken: a numbered timeline with each step's name, type, status, the way it left, its time and duration, and any detail. Steps the run never reached are listed underneath.

A run started on an earlier version carries on with that version's steps; the inspector says so. Show the path in the builder opens the workflow with this run's route drawn on the canvas.

Cancel, retry and skip

Cancel run…: stops a running or waiting run where it is and withdraws whatever it was waiting for (an approval, a signature, a sub-workflow). A reason is required. It cannot be undone.
Retry failed step…: runs the failed step again, for real, and carries on from there if it succeeds. An e-mail is sent again and a webhook called again.
Retry on version N…: moves the run onto the newest published version and retries there, for a step that failed because of how it was set up and has since been fixed and published.
Skip…: on a waiting step marked "A person may skip this step while it is waiting". The run carries on as though the step had completed (an approval as approved, a signature as signed). A reason is required.

These actions are for architects. Someone with a role on a workflow sees its runs read-only. People who can edit a record can also act on its runs from the record's Processes pane; see The Processes Pane.

Statuses

Running: being walked now. Waiting: parked at a Wait, an approval, a verification, a signature or a sub-workflow.
Done, Failed or Cancelled: finished. Steps can also be Skipped or Not reached.

What goes wrong

Many runs waiting, none overdue moving. The Workflow Resume task is off; the banner says so.
A run Running for hours. Its process was killed. The resume task marks it Failed after 30 minutes without progress, and it can then be retried.
"Step budget exhausted" or "Stopped after 200 steps in a single pass". The workflow loops. A run may take 1,000 steps, plus 50 for each row a For each step works through, and never more than 100,000; 200 steps in one pass without reaching a Wait or the end also stops it.
A failed run still has open requests. Parallel branches may still be parked; cancel the run to withdraw them if nobody will retry it.

Worked example

A customer asks why their order was never confirmed. The operations lead opens Workflow Run History, enters the order number under Record number and finds a failed run. Why it failed says the E-mail step had no account to send from. They choose an account on the step, publish version 3, return to the run and use Retry on version 3. The e-mail goes out and the run finishes as Done.

Recommendations

Check the Failed tile daily for any workflow that matters.
Read a real run before changing the canvas.
Give a reason worth reading when you cancel or skip; it stays in the history.
Turn on failure alerts so owners hear about failures; see Who Can Use a Workflow.
Leave test runs out when you are reviewing real activity.

Versions and Publishing

A workflow has a draft you edit and published versions that run. Saving changes only the draft; publishing turns the draft into a new numbered version and makes it live. Runs already under way keep the steps they started with, so you can improve a workflow without disturbing work in flight.

Where to find it

Architect Panel → Automation:

Workflow Builder — Save draft, Publish…, Disable or Activate, and More → Versions…, Duplicate workflow, Export as JSON, Import from JSON… and Delete workflow…

Draft, active and disabled

Draft: never published. Saving writes what you drew, so you can validate, simulate and test it exactly as drawn, but nothing starts it on its own.
Active: published and switched on. The header shows the version (v1, v2…). After any later save it also shows Unpublished changes: what runs is still the last published version.
Disabled: published but switched off. Nothing new starts it; runs already under way carry on.

The trigger settings (target datastore, how it starts, the schedule) are part of the draft too, so changing them does not affect the live workflow until you publish.

Publishing a version

Press Publish…. Unsaved changes are saved first.
Read the lead: it says which version this will be and what will start the workflow from then on.
Fill in What changed in this version, for example "adds a manager approval for orders over 5,000".
Press Publish and activate. The toast confirms "Version N is live and the workflow is active."

Publishing validates the draft first. With errors it refuses ("Fix 2 problems before publishing.") and lists them. With nothing changed since the live version it refuses with "Nothing has changed since version N". For a workflow that starts when a record changes, publishing also makes sure the datastore passes its changes to the engine.

Runs already in progress

A run carries on with the version it started on; new runs use the new version. After publishing you are told how many runs are still on earlier versions.
If runs are waiting at a step the new version removes, or replaces with a different kind of step, publishing stops and warns that they would be unable to continue. Publish anyway goes ahead.
A failed run can be moved onto the newest version with Retry on version N in Workflow Run History.

Disabling and activating

Disable asks for confirmation, then stops anything new from starting the workflow. Activate switches it back on. Only a published workflow can be activated; a draft says "This workflow has never been published. Publish it to make it active."

Versions

More → Versions… lists every published version with Published, By, Steps and Notes, and marks the live one. Open in editor replaces the drawing and trigger settings in the editor with that version. Nothing changes for real until you save and publish, which is how you roll back.

Duplicate, delete and restore

Duplicate workflow makes a new draft called "Copy of …" from the current drawing.
Delete workflow… stops it starting new runs and moves it to Show deleted in the library. If runs are in progress you are asked to confirm, and they are cancelled. The toast offers Undo.
Restore (in Show deleted) brings it back: a published workflow returns disabled, a never-published one returns as a draft.

Export and import

Export as JSON downloads the drawing and its settings, naming the target datastore by its table name.
Import (or Import from JSON…) opens the file as a new, unsaved workflow called "… (imported)". If its datastore does not exist here you are told to choose another. Review it, then Save draft.

Creating, importing, duplicating, deleting and restoring are for architects. Publishing, disabling and activating also need the owner role on that workflow.

Worked example

A purchase approval workflow is on version 2 with twelve orders waiting for approval. The finance director wants a second approver above 25,000. The architect adds a Condition and a second Approval on the draft, simulates an order of 30,000, and publishes with the note "second approval over 25,000". The twelve waiting orders finish on version 2; orders sent for approval from then on follow version 3. When a problem appears a week later, Versions…, Open in editor on v2, then Publish, rolls it back as version 4.

Recommendations

Always write the version note: it is the change log.
Read the stranded-runs warning before choosing Publish anyway.
Roll back by publishing an old version, not by editing the live one in a hurry.
Disable rather than delete a workflow you may want back.
Export before a large change so you have a copy outside the system.

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

Press Test….
On a published workflow, choose under What to test: "Your draft, with the unpublished changes" or "The live version".
Check the Datastore, type part of the record's name or its number in Find the record, and pick it under Record.
Optionally open Sample data and decisions (below).
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.

Placeholders and Variables

Placeholders let a step use values that are only known when it runs: a field of the record, something an earlier step found or created, today's date. You write them in double braces, such as {{email}}, and the engine replaces each one with its value at that moment. Set variables gives a value a name so later steps can reuse it.

Where to find it

Architect Panel → Automation:

Workflow Builder — any step field with a { } button accepts placeholders; the button opens Insert a value

Inserting a value

Click into a field that takes a template, such as an e-mail's Subject or an Update record value.
Press the { } button beside it. Insert a value opens.
Type in Find a field or value to filter, then pick one. It is inserted where the cursor is.

The list offers the record's fields and the values earlier steps make available, with their exact spelling. Picking from it is safer than typing, because values from steps include each step's internal key.

What you can use

{{field}} or {{record.field}}: a field of the record the workflow runs on, such as {{title}} or {{record.amount}}.
{{vars.name}}: a variable set by a Set variables step.
{{found.field}}: a field of the record a Look up step found, where "found" is what you entered in its Save it as box.
{{item.field}}: on a For each step's Each row path, a field of the current row ("item" is the default name in Call each row).
{{created.step.ID}}: the ID of the record a Create record step made.
{{webhook.step.status}}, .body, .json.key and .error: the reply to a Webhook step, and why it failed.
{{sla.step.due}}: the deadline an SLA timer worked out.
{{run.ID}} and {{run.version}}: the run's number and the version it runs on.
{{now}} and {{today}}: the date and time, or the date, in the form fields and comparisons use. {{today.text}} is the date as people read it, such as 4 Oct 2026.
Relative dates: {{today-30}} and {{today+7}} (days), {{now-2h}}, {{now+90m}} and {{now-1d}}. For example, a Look up for invoices with due date is less than {{today-30}} finds those more than 30 days overdue.

The AI decision and AI check steps add their own answers under the name in Save the answer as; see Branching on the Answer, and When Jev Cannot Answer.

Set variables

Add a Set variables step before the steps that need the values.
Under Variables, add a row per value: a Name (letters, digits and _) and a Value, which may itself use placeholders.
Use them later as {{vars.name}}.

Variables are how you feed the workflow library's functions: set the inputs a function reads, call it with a PHP function step working on "The run's variables", and read its answers back as {{vars.answer}}. See Webhooks, Functions and Extension Steps.

Some names are reserved for the engine's own values and cannot be used to save an AI answer, among them record, run, vars, created, webhook, item, now and today.

Where placeholders work

Message fields: recipients, subjects, bodies and titles.
Values written by Update record, Create record and Set status.
Values in Condition rows, Look up and For each rules, and the Trigger's start conditions.
The Record ID box on steps that act on another record, such as {{found.ID}}.
Approver, Wait's Or until, Webhook URL, headers and body.

What goes wrong

A blank where a value should be. A placeholder that cannot be resolved becomes empty text. Check the spelling, and that the step that provides it ran before this one on every path.
A value from the wrong record. A flat name such as {{status}} reads the record first. Use {{found.status}} or {{item.status}} for another record's field.
A date comparison that never matches. Compare dates with {{today}} or {{now}}, not with {{today.text}}, which is for people to read.

Worked example

A credit control workflow looks up the customer of each overdue invoice and saves it as "customer". A Set variables step sets from to {{item.due_date}} (the function reads "from" and counts to today), a PHP function step runs "Days between two dates" on the run's variables, and a Condition checks vars.days is at least 30. The final e-mail goes to {{customer.email}} with the subject "Invoice {{item.number}} is {{vars.days}} days overdue", and Simulate shows the subject filled in for a real invoice.

Recommendations

Pick from Insert a value rather than typing step references.
Name look-ups for what they find ("customer", "order") so placeholders read clearly.
Work values out once in Set variables, then reuse them.
Simulate to see placeholders filled in before anything is sent.

Record Steps

The Records group of the Steps palette changes and reads data: Update record, Set status, Create record, Convert record, Look up and Set variables. Every write they make goes through the platform's normal save, so the record's audit trail, table rules, field security and validation apply exactly as they would to a person saving a form.

Where to find it

Architect Panel → Automation:

Workflow Builder — the Records group of the Steps palette

Which record a step changes

Update record, Set status and SLA timer have a Record to change (or Stamp the deadline on) choice:

The record the workflow runs on: the usual choice.
The current row of a For each step: offered when the step sits on that loop's Each row path.
Another record (give its ID): choose In datastore and give the Record ID as a placeholder, such as {{found.ID}} or a created record's ID.

A scheduled run that is not started against a record has no record of its own, so choose a loop row or another record there.

Update record

Choose the record to change.
Under Set these fields, add a row per field: the Field and its New value. Values may use {{field}}, {{now}} or {{vars.name}}.

On an ERP document, an Update record that names the status column is refused: use Set status, which makes the document's own declared move.

Set status

Choose the record, then the Status field.
Enter the New status.
For an ERP document, optionally give a Reason (ERP documents), recorded on the document's history.

The change is noted in the record's activity. On an ERP document (a purchase order, requisition, supplier or sales invoice) the step makes the document's declared move to that status, with the approvals, checks and postings that move applies. A move that is not declared from the document's current status fails the step and says where it can go. Moves that need a reason get the step's name when Reason is blank.

Create record

Choose Create a record in.
Under With these values, set each field of the new record.
For an ERP document, fill in Its line (ERP documents): item, qty, unit_price and description, or the lines datastore's own field names.
Optionally change Link the new record as (default "created"): the relationship shown in both records' links.

The new record is linked to this one and numbered when its datastore has a numbering scheme. Later steps use its ID as {{created.step.ID}}. An ERP document is created through the document engine, at its opening status with its counterparty defaults.

Convert record

Choose Convert into a record in.
Leave Convert this record instead (optional) blank to convert the run's record, or choose a datastore and give Its record ID.
Under Copy fields, map each field From this record Into the new record.
Optionally change Link the new record as (default "converted").

Between two ERP document types, such as a requisition into a purchase order, the document engine does the conversion: every open line is copied and linked, the source moves on, and no field mapping is needed.

Look up

Choose Look in.
Add rules under Find the record where, such as customer ID equals {{customer_id}}.
Enter Save it as, for example "customer". Letters, digits and _ only, starting with a letter.
Connect Found and Not found.

The first matching record is used, and later steps read it as {{customer.field}}. With no rules it finds the first record in the datastore, and Validate warns.

Set variables

Works out values once and names them for later steps as {{vars.name}}. See Placeholders and Variables.

What goes wrong

The step failed with a validation message. The write broke a field rule or permission, exactly as a form save would. The reason is in the step's detail in the run history.
"is not a field of" warnings: a field name no longer exists on the datastore.
"No field values: the new record will be blank." A Create record with nothing set.
A loop of saves. An Update record on the run's own record re-triggers an update workflow; use the Trigger's start conditions.

Every step here has If this step fails, carry on with the next one. Off, a failure stops the run.

Worked example

A lettings team converts an accepted application into a tenancy. A Look up saved as "property" finds the property by its reference. Convert record turns the application into a tenancy, copying the applicant's name and e-mail and linking the two. Set status moves the application to Converted, and Update record on Another record, the property ({{property.ID}}), sets its availability to Let.

Recommendations

Use Set status for statuses, especially on ERP documents.
Name look-ups for what they find.
Always connect Not found, even to an End step with a message.
Prefer Convert record where the new record comes from this one, so the two stay linked.

Message and People Steps

Message steps tell people things: E-mail, SMS, WhatsApp, Letter and Notify. People steps wait for a person to act: Approval, Verification and Signature. A people step parks the run until the person answers, then sends it down the port that matches the answer.

Where to find it

Architect Panel → Automation:

Workflow Builder — the Messages and People groups of the Steps palette
Approvals Inbox — where back-office approvers decide Approval steps

E-mail

To, Cc, Bcc: addresses or {{field}}, several separated by commas.
Send from: with more than one e-mail account, choose one; the step will not guess. See E-mail Accounts.
Template, or a Subject and Message written here.

SMS and WhatsApp

SMS: To (a mobile number or {{field}}), Send from, Message, and optionally Message template, GOV.UK Notify template (required for a GOV.UK Notify account), Sender ID and Provider reference. Every 160 characters is one billed part (70 with characters outside the GSM alphabet).
WhatsApp: To (international form or {{field}}), Send from, and Send: An approved template (Template name exactly as approved, Template language, Template parameters by position) or Free text, which works only inside WhatsApp's 24-hour reply window.
Both offer Do not keep the message text in the log for one-time codes and reset links. See SMS & WhatsApp.

Letter

Write to (blank for this record, or datastore:id for another), Send from (required with more than one letter account, because a letter cannot be recalled), Which address (general, correspondence, billing or registered office), and the Document template ID printed as the letter, or a GOV.UK Notify letter mapping. See Letters & Physical Mail.

E-mail, SMS, WhatsApp and Letter each have Carry on if it cannot be sent. Off, a failed send fails the run.

Notify

Tell: e-mail addresses, {{field}}, or group:ID or name for everybody in a security group. Or pick a group fills it in for you.
How: In the app (their in-tray), By e-mail, or Push notification (see Push Notifications).
Title and Message.

Approval

Enter a Request title, such as "Approve {{name}}": what the approver sees.
Enter the Approver: an e-mail address, group:id or name, team:key, several of these separated by commas (any one may decide), or a {{field}} holding one. Anything else, such as "Smith, John", is read as one person's name.
Tick E-mail them a link to decide for approvers without back-office access, then choose Send the e-mail from and an E-mail subject.
Connect Approved and Rejected.

The request appears in the approver's Approvals Inbox, on their "Waiting for my approval" page, in their in-tray and on the record's Processes pane. A rejection with no Rejected path ends the run. See Approvals.

Verification

Choose the Verification type, and Who is verified: the person whose e-mail is on the record (then Their e-mail is in) or the person who started the run. The run goes down Verified or Rejected. Verification types must be set up first; see User Verification.

Signature

Choose the Signature type (it decides the provider, the signer roles and their order), the field holding the document under Document to sign is in or a fixed document under Or always this document, a Subject and Message, and under Signers the record's name and e-mail fields for each signer role. The run goes down Signed or Not signed. See Electronic Signatures.

Approval, Verification and Signature can be marked A person may skip this step while it is waiting. Skipping counts as approved, verified or signed and needs a reason.

What goes wrong

"With more than one account, choose one." The step will not guess which account to send from.
An approver never sees the request. The approver was typed as a display name nobody matches, or they have no back-office access and the e-mail link was not ticked.
No verification or signature types to choose. Set them up first; the step's list says so.

Worked example

A membership application workflow e-mails the applicant an acknowledgement, then asks group:Membership Committee to approve with Request title "Approve {{applicant_name}}". On Approved, a Notify step tells the membership secretary in the app and a Letter sends the welcome pack; on Rejected, an E-mail gives the outcome. Simulate shows the exact wording of all three messages before anything is published.

Recommendations

Choose the sending account on every message step.
Name approvers by e-mail address or group, never by display name.
Tick the e-mail link for approvers outside the back office.
Connect every rejection route, even if only to tell the requester.

Loops, Sub-workflows and End Steps

Three Flow steps shape a run as a whole. For each repeats a path for every matching row, Sub-workflow hands part of the work to another workflow, and End finishes the run with a result and a message. Together they let one workflow work through many records and keep large processes in readable pieces.

Where to find it

Architect Panel → Automation:

Workflow Builder — For each, Sub-workflow and End are in the Flow group of the Steps palette
Workflow Run History — parent and child runs are linked from each other

For each

Add a For each step and choose Child records in: the datastore holding the rows.
Choose Linked by field: the field on those rows that holds this record's ID (an order's lines, say). Leave it empty to take every row matching the rules, which is how a scheduled workflow works through records.
Optionally add rules under Only rows where. Values may use placeholders, such as due date is less than {{today}}.
Set At most this many rows (500 when blank, 5,000 at most).
Optionally rename Call each row (default "item").
Draw the Each row path: the steps that run for every row. Connect When done to what happens after the last row.

On the Each row path the current row is {{item.field}}. When a pass reaches the end of the path, or comes back into the For each step, the next row is taken. Steps such as Update record can act on "The current row of" the loop.

A run may take 1,000 steps; each row a For each works through raises that by 50, up to a ceiling of 100,000. Work much larger than that belongs in a scheduled workflow that starts one run per record.

Sub-workflow

Build and publish the workflow to be called first. It must be active.
Add a Sub-workflow step and choose Workflow to run. Workflows that are not active are marked in the list.
Set On record: "current" for this record, or a placeholder holding the ID of a record of the other workflow's datastore, such as {{found.ID}} or {{item.ID}}.
Tick Wait for it to finish before carrying on if this run should wait. It then fails if the child fails.

In Workflow Run History the child run shows Started by with a link to the parent, and the parent lists its Child runs. A workflow cannot call itself, and runs can nest at most five deep in one go.

Templates that bundle a sub-workflow (Month-end close, New customer onboarding) create it alongside the main workflow; publish it too.

End

Finish the run as: Done or Failed.
Message: recorded against the run; it may use placeholders.

End stops the whole run there, including every open parallel branch and loop. In a workflow that runs before a record is saved, ending as Failed refuses the save and the message is what the person saving sees. A run that simply runs out of steps also finishes as Done; an End step lets you say why.

What goes wrong

"Connect the 'each' path - it is what runs for every row." The For each step has nothing to repeat.
"Step budget exhausted": the When done path leads back into the For each, or a loop has no exit.
"The chosen sub-workflow no longer exists." It was deleted; choose another.
A parent run waits for ever. The child is waiting too (for an approval, say). Open the child from Child runs to see what it waits for.
The For each did nothing. No rows matched, or the link field is wrong; Simulate shows which steps ran on the Each row path.

Worked example

A wholesaler checks stock every morning. A scheduled workflow uses For each over active items with a reorder point, at most 500. On the Each row path, Set variables and two library functions work out stock on hand and a reorder quantity, and a Condition asks whether the item is at or below its reorder point; Yes raises a requisition. When done goes to End, Done, with the message "All items checked". The Stock reorder template builds exactly this.

Recommendations

Always set At most this many rows to a number you expect.
Prefer one run per record for scheduled work that waits or asks people.
Publish sub-workflows before their parent.
End rejected and failed paths with a message so the run history explains itself.

Webhooks, Functions and Extension Steps

The Other systems group covers what the built-in steps cannot do on their own: calling another system over HTTPS, working out a value with one of the workflow library's functions, or running custom code from a published extension. Because these steps run with the engine's rights rather than the editor's, only an architect may add or change them.

Where to find it

Architect Panel → Automation:

Workflow Builder — Webhook, PHP function and Extension step are in the Other systems group of the Steps palette
Extensions — where the code an Extension step runs is approved and put live

Webhook

Enter the URL. It must start with https://; redirects are not followed. It may use placeholders.
Choose the Method: POST, PUT or PATCH.
Add any Headers (a name and a value, such as an authorisation token). Content-Type: application/json is always sent.
Leave Body blank to send the record as JSON, or write the body with placeholders. A body that is not valid JSON is sent as written, and Validate warns.
Set Give up after (seconds): 15 when blank, between 1 and 120.
Connect Next and On error.

A failed call goes down On error when it is connected; otherwise the run fails. Tick Carry on down 'next' even if the call fails to ignore failures altogether. Later steps can read the reply as {{webhook.step.status}}, {{webhook.step.body}} and {{webhook.step.json.key}}, and after a failure the reason as {{webhook.step.error}}.

PHP function

The Function list offers the workflow library's functions (shown as "Library: …") and any function your installation has declared for workflows. The library needs no code:

Days between two dates: reads from and to (default today), writes days.
Percentage of a total: reads value and of, writes percent and over.
Work out a reorder quantity: reads on_hand, reorder_point, reorder_qty and max_level, writes order_qty and below.
ERP: stock on hand of an item, ERP: is an item at or below its reorder point?, ERP: a project's spend against its budget, ERP: three-way match a supplier invoice now, ERP: accept a supplier invoice's match differences and ERP: run a company's reminder ladder (dunning): ask the ERP engines the same questions their own screens do.

The help under the list says what the chosen function reads and writes. To use one:

Add a Set variables step that sets the names the function reads.
Add the PHP function step, choose the function, and set Works on to "The run's variables".
Use its answers as {{vars.name}}, for example in a Condition.

Works on can also be the run's record, the current row of a For each, or what a Look up found. A function's changes are seen by later steps but not saved; add an Update record step to save them. A missing or non-numeric input fails the step with a reason.

Extension step

Have the extension written, approved and published for the workflow step hook; see Extensions.
Add an Extension step and choose the Extension.
Add Settings for the extension as names and values; values may use placeholders.
Connect Next and On error.

A failure, a timeout or an extension that has been switched off goes down On error when it is connected; otherwise the run fails with the reason.

AI decision and AI check

The AI decisions group asks TypeSafe Jev to choose an option or judge a statement from fields of the record, routing unsure answers to a person. They are documented in AI Decision and AI Check Workflow Steps.

What goes wrong

"Webhooks are sent over HTTPS only": the URL starts with http://.
"is not a custom function this installation allows": the function is not a library function and has not been declared for workflows.
An editor cannot save. Only an architect may add or change these three steps; the editor role cannot.
The function's answer is not saved. Functions change the run's values only; add an Update record step.
Simulate did not call the other system. By design: webhooks, extension steps and custom functions are described in a simulation, not run.

Worked example

A records team must tell its finance system when a contract is marked Ready. The webhook-on-change template gives them a Condition on the status, a Webhook to https://finance.example.com/hooks/contracts with the record as JSON, on Next an Update record that writes "sent", the time and the HTTP status into the contract's sync field, and on On error an Update record that writes "failed" plus a Notify telling the administrators the reason and the HTTP status. An architect adds the finance system's token as a header before publishing.

Recommendations

Always connect On error on a Webhook.
Use library functions before asking for custom code.
Keep secrets in headers, not in the URL.
Record the outcome of each call on the record so it can be resent.

Who Can Use a Workflow

Architects can do everything with every workflow. Anyone else can be given a role on one workflow at a time, so a process owner (the financial controller who owns the month-end close, say) can see its runs, test it, change it or publish it without becoming an architect. Owners can also be alerted when a run fails.

Where to find it

Architect Panel → Automation:

Workflow Builder — open a workflow, then More → Who can use it…
Workflow Run History — shows people with a role the runs of their workflows, read-only

Admin Panel → Processes:

Approvals Inbox — its My processes and Run History buttons take people with a role to their workflows

The four roles

Viewer: sees the workflow (a read-only canvas), its versions and its runs.
Run only: also simulates it and test-runs its live version on a record.
Editor: also changes and saves the draft, and tests the draft. Cannot publish.
Owner: also publishes, activates or disables it, runs its schedule now, decides who has which role, and is alerted when a run fails.

Some things stay with architects whatever the role: creating, importing, duplicating, deleting and restoring workflows, and cancelling, retrying or skipping runs in Workflow Run History.

Giving someone a role

Open the workflow and choose More → Who can use it…. The dialog lists the roles already given.
Under Add someone, choose Who: A group or A person.
Pick the Group, or type a name or e-mail in Person and pick from the list.
Choose the Role and press Add.
Tick Alert the owners when a run fails if owners should hear about failures.
Press Save roles.

Only an architect or an owner of the workflow can change roles; everyone else sees the list read-only. In the library, an architect sees a badge with the number of roles given on each workflow.

What an editor may not add

A workflow runs with the engine's rights, not its editor's. So an editor cannot add or change a PHP function, Extension step or Webhook; an architect does that. A Sub-workflow step an editor draws may start only a workflow the editor could run themselves (Run only or above), chosen from the list rather than given by a placeholder.

Failure alerts

With alerts on, when a run fails every owner (a person, or each member of an owner group) gets an item in their in-tray naming the workflow, the record and why, with links to the run in Workflow Run History and to the record's Processes page. There is at most one alert per workflow per hour. Test runs, sub-workflow runs (the parent alerts instead) and before-save checks that refuse a save do not alert.

How people with a role find their workflows

The Workflow Builder lists only the workflows they have a role on, each with "Your role".
Workflow Run History shows only those workflows' runs, read-only.
The Approvals Inbox shows My processes and Run History buttons to anyone with a role, so back-office users without the Architect Panel can reach both.
A failure alert links straight to the run.

What goes wrong

"The Workflow Builder is for architects and for people given a role on a workflow." The person has no role on any workflow. Give them one.
Test… is missing. They are a Viewer; Run only or above can test.
"A Sub-workflow step can only start a workflow you may run yourself": give the editor Run only on the called workflow too, or ask an architect.
No alert arrived. Alerts are off, the failure was a test run, or an alert was already sent in the last hour.

Worked example

An architect builds a month-end close workflow from the template. They open Who can use it…, add the Finance group as Viewer and the financial controller as Owner, and tick Alert the owners when a run fails. The controller opens the Approvals Inbox, presses My processes, sees the workflow with "Your role: Owner", simulates it against last month's period and publishes a small change to the wording of the final notice. When a run fails at month end, the alert in their in-tray takes them straight to the failed step.

Recommendations

Give every important workflow an owner outside the architect team.
Grant roles to groups rather than individuals where you can.
Turn on failure alerts for anything customers or finance depend on.
Use Editor for people who refine wording; keep Owner for whoever answers for the process.

The Processes Pane

The Processes pane shows, on one record, every workflow that has run on it, what it is waiting for, and the processes you can start on it. It is where the people who work a record approve what is waiting, start a manual workflow, and see why a process stopped, without needing Workflow Run History.

Where to find it

Architect Panel → Automation:

Workflow Run History — Processes on this record, in a run's details, opens the record's Processes page
Approvals Inbox — the Processes button on a request's card opens the same page

Admin Panel → Processes:

Approvals Inbox — the same Processes button, for back-office users

Where the pane appears

On a record's screen the pane is a Processes tab; the number in brackets counts what is still open. The tab appears when the record has a workflow run or a pending approval, or when its datastore has an active workflow that is started by hand. The same pane also opens as a page of its own, titled "Processes: " and the record's name, from the buttons above and from the link in a failure alert. The page suits people who do not use the generic record screen, such as ERP users working through their desks.

What the pane shows

Processes on this record: how many runs, how many are in progress and how many failed.
Run a workflow: a list of the active workflows of this datastore that are started by hand, and a Run button.
Waiting for a decision: each pending approval with who it is for and since when, and Approve and Reject… for the person who may decide it.
The runs table: Workflow (with its version, and "(test)" for test runs), Status, Where it is (the step it waits at, or why it failed), Started, and Details. Show older runs pages back.

Starting a workflow on a record

Open the record's Processes tab.
Choose the workflow under Run a workflow.
Press Run. The new run appears in the table.

Starting a process needs permission to edit the record. Without it, the pane only says how many workflows can be run on records like this one by someone who may edit it.

Acting on a run

Press Details to see the run's steps, the way each left, what it is waiting on, and its error. The buttons shown are only those you may use:

Cancel run…: stops the run and withdraws what it waits for. A reason is required.
Retry the failed step…: runs the failed step again, for real.
Retry on version N…: moves the run onto the newest published version and retries there.
Skip 'step'…: on a waiting step marked as skippable; the run carries on as though it had completed. A reason is required.

Who may do what

See the pane: anyone who may read the record. Architects always.
Approve or reject: the person the request names, who must also be able to read the record.
Run a workflow and skip a skippable step: anyone who may edit the record.
Cancel and retry: someone who may edit the record and has back-office (Admin Panel) access.

For ERP records, access follows the person's ERP role for that area and their access to the record's company.

What goes wrong

No Processes tab. Nothing has run on the record, nothing is waiting, and no active manual workflow targets its datastore; or you cannot read the record.
"This record cannot be shown" on the Processes page: the record does not exist or you have no access to it or its company.
Retry is not offered. Only a failed run can be retried, and you need back-office access.

Worked example

A financial controller opens an accounting period's Processes page from a link in the Approvals Inbox. Under Run a workflow they pick the month-end close and press Run. The table shows the run Waiting at the period checks. Two days later a branch has failed because a task datastore field was renamed; an architect fixes and publishes the workflow, and the controller's colleague with back-office access uses Retry on version 4 from the same page.

Recommendations

Use manual workflows for on-request processes, so staff start them from the record.
Mark waits for people as skippable, so a stuck run can be released from the record.
Point people at the Processes page when they ask "what is happening to this record?".
Write reasons for cancels and skips that the next person will understand.