Workflow Steps

Steps are what a workflow does after the trigger fires. Each step runs in order, passing control to the next step when it finishes. A workflow can have as many steps as you need.

There are six step types:

Step type	What it does
Action	Performs an operation — send a message, create a record, promote a member, etc.
Delay	Pauses the run for a period of time before continuing
Branch	Checks a condition and takes one of two paths
Switch	Checks a condition against several possible options and takes the matching path(s)
Read	Looks up a single record and makes it available to later steps
For Each	Loops over multiple records and runs a sub-sequence of steps once per record

New-step defaults

These are starting settings, not a finished automation:

Step	Starting settings
Action	No action selected; Workflow record target
Delay	One day, Recheck trigger on, no execution window
Branch	No condition
Switch	Match first, two unconfigured cases
Read	Member records, no selected fields or filter
For Each	Member records, no filter, limit 100

Choose the record type, filters, fields, and connections before publishing. In particular, an unfiltered loop is not automatically limited to the member who started the parent run.

Action

An Action step performs an operation. You pick the action from a list and fill in the required fields.

Target tells Kanri which record to act on:

Workflow record — the record the current run is about. It is offered when the action expects that record type.
Expression — a record ID supplied directly or through the reference picker, including an ID returned by an earlier step.
For a create action, the editor shows that it creates a new record instead of asking you to select an existing one.

Referencing data in fields: When filling in an action’s fields, you can pull in values from the triggered record or from an earlier step’s output. Click the [$] button next to a field to open the data reference picker — it shows all available fields from the triggered record and any previous step outputs you can insert.

Continue on error: This is off by default. When on, an action’s validation errors can be recorded and skipped so the run continues, for example when no eligible recipient has the chosen contact method. It does not ignore every kind of failure: missing references, unexpected processing errors, and actions that require opening a browser page can still fail the run.

Run history marks runs with an Errors ignored badge when a step failed but the workflow continued. Open the run to see the failed step and its validation details.

Available actions: See Available Actions Reference for the complete list.

Delay

A Delay step pauses the run before continuing to the next step.

Duration options:

Fixed time — wait a set number of minutes, hours, or days.
Until a date field — wait until an available stored date on the run’s record, such as a subscription’s end date. Set Offset days to run before or after that date: negative numbers run before it, positive numbers run after it, and zero uses the date itself.

Execution window (optional): After the delay elapses, choose a Time of day and allowed Days of week, in your school’s timezone. This is a chosen resume time, not a start-to-end office-hours range. When first enabled, the editor suggests 9am Monday to Friday. With no days selected, any day is allowed.

Re-check trigger condition: New delays have Recheck trigger on. When the delay finishes:

Condition Becomes True and filtered Recurring Schedule runs continue only if the record still matches the original filter.
Condition Stops Being True runs continue only if the record still does not match the original filter. If it matches again, the run is cancelled.

This is usually the right behavior — for example, a “your subscription is expiring” reminder shouldn’t fire if the member already renewed during the delay.

Missing or deleted records do not pass these checks. Manual, event, and date-field triggers do not perform a filter check here.

Turning re-checking off does not bypass a workflow-level exit condition.

Branch

A Branch step evaluates a condition and sends the run down one of two paths — “if true” or “if false.”

You build the condition using the same filter builder used in reports and groups.

Example uses:

After a delay, check if a member’s membership is still inactive. If inactive, send a follow-up message. If active again, end the run.
Check if a member has an email address on file. If yes, send an email. If no, send an SMS.
In an Invoice workflow, check the run’s invoice amount before choosing the next action.

Either path can have more steps, including more branches. You can build fairly complex decision trees this way.

Branching on data from other records: A branch filters against the run’s current record. It does not switch its target to a Read step’s output. Use relationships available in that record’s filter builder for related-record conditions. Read outputs can supply later action parameters, but do not become a separate Branch target.

Switch

A Switch step is like a Branch step with more than two possible outcomes. You add one case per outcome, each with its own condition, plus a default path used when nothing matches.

Choose a mode:

Match first — checks cases in order and uses the first match’s connected path. If nothing matches, or that first match has no connected path, it uses the default.
Match all — starts child runs for all matching cases with connected paths. These run independently at the same time, and the parent waits. If there are no connected matching paths, it uses the default instead. Use this when more than one reminder may apply to the same person.

Example uses:

Route a new lead to a different follow-up sequence depending on which class they inquired about (Match first).
Send one or more targeted reminders to a member depending on which conditions apply to them at once — overdue balance, expiring membership, low attendance — without the reminders being mutually exclusive (Match all).

Read

A Read step looks up a single record (or an aggregated value) and makes it available to later steps.

This is useful when you need fields from another specifically identified record, such as an invoice whose ID you already know.

You choose the record type, define a filter to find the right record, and pick the fields you want. Later steps can reference that data using the [$] button.

If no record matches, the Read result is empty. A later action that references a missing field can fail; it is not automatically replaced with blank text. Make the filter precise enough to identify the intended record. Read does not offer a “most recent” sort setting, so do not assume an unconstrained filter returns the latest invoice.

Example uses:

Read a specifically identified invoice to get the amount due.
In a membership workflow, read the related program to include the program name in a message.

For Each

A For Each step matches multiple records and runs a sub-sequence of steps once per matched record. The parent run waits for all iterations to complete before continuing.

This is useful when you want the same action to happen for every item in a set. For example:

In a school-level workflow, send a message to every active member in a specific program.
In a member workflow, loop over every open invoice and send a separate reminder for each one.

You set a limit (the maximum number of records to process per run; new loops default to 100) and define the steps that should run for each matched record. Inside the loop, “this record” refers to the current iteration’s record. Use the [$] button to access it. If more records match than the limit, extra records are not automatically processed in another batch. Use a narrower filter rather than assuming a particular ordering.

Connecting steps

Steps are connected in the workflow editor, which runs left to right. Each step has an outgoing connector on its right side.

Action, Delay, and Read steps have one outgoing connection.
For Each has a loop-body connection and an After connection for continuing once the child runs complete.
Branch steps have two outgoing connections: “if true” and “if false”.
Switch steps have one outgoing connection per case, plus one for “default”.
A step with no outgoing connection is a terminal step — the run ends there.

See Building in the Editor for how to add, connect, and rearrange steps on the canvas.

Next steps

Available Actions Reference — complete list of action step types
Building in the Editor — how to use the visual canvas
Create Your First Workflow — guided tutorial