How Workflows Work

Before you build your first workflow, it helps to understand how Kanri thinks about them. This page explains the key concepts.

Triggers, steps, and runs

A workflow is a saved automation made up of two parts: a trigger and a sequence of steps.

The trigger is what causes the workflow to start. When the trigger fires, Kanri creates a run — a single execution of that workflow.

The steps are what happen during the run. Steps execute in order. Each step does something (sends a message, waits, checks a condition) and then hands off to the next step.

One workflow can produce many runs over time. For example, a “welcome message” workflow triggers every time a new member is created — each new member gets their own run.

The record type

Every workflow is scoped to a record type — the kind of record the workflow is about. You choose this when you create the workflow, and it stays fixed forever.

The record type matters because it determines:

What fields you can filter on in your trigger
What “this record” refers to inside your steps (so an action step on a Member workflow targets the member that triggered the run)

Choose from the record types available in the creation form, such as Member, Membership, Invoice, Booking, Subscription, Program, and Level.

Versions and the draft-publish lifecycle

Workflows are versioned. Here’s how it works:

When you create a new workflow (or edit an existing one), your changes go into a draft version. Use Save Draft to save changes; the editor does not automatically save every edit.
When you’re ready to go live, you click Publish. This freezes the draft into a permanent, numbered version and immediately makes it the active, enabled version.
From that point on, any trigger firing uses the published version. If you need to make changes, you edit the workflow again — a new draft is created, and the live version keeps running unchanged until you publish again.

This design means an edit you’re working on can’t accidentally affect runs that are already in progress. A member who’s mid-way through a multi-day workflow sequence stays on the version that was live when their run started, even if you publish a new version tomorrow.

Key states a workflow can be in:

State	What it means
Draft only	Created but never published. Trigger never fires.
Published, enabled	Live. Trigger fires. New runs are created when triggered.
Published, disabled	Automatic triggers and record actions are paused; in-progress runs were cancelled. Test Run can still start a real run.
Published + new draft	A live version is running, and you’re working on the next version.

How a run works

When a trigger fires for a record (say, a new member is added):

Kanri creates a run for that member and pins it to the current published version.
The run starts at the first step.
Each step executes and passes control to the next.
Some steps can pause the run temporarily (a Delay step waits before continuing).
The run finishes when it reaches a step with no “next” step defined.

Each run tracks its own state independently. If you have 50 members in different stages of the same workflow, each one is its own run at its own step.

Run statuses:

Status	What it means
Running	The run is executing steps or waiting for a Delay step to finish
Waiting	The run is waiting for child runs, such as a For Each loop or Match all Switch
Done	The run completed successfully
Failed	A step encountered an error
Cancelled	The run was cancelled — see Run History for every reason this can happen

Trigger re-checking

Many triggers are condition-based — they fire when something becomes true (for example, “member’s subscription is expiring”). Once the trigger fires and the run starts, Kanri can optionally re-check that condition again later.

New Delay steps have Recheck trigger on. For Condition Becomes True and filtered Recurring Schedule workflows, this checks the original filter again when the delay finishes. If the record no longer matches, the run is cancelled instead of continuing.

Manual, action-event, and date-field triggers do not gain an extra eligibility check from this switch. An event-triggered welcome message does not expire simply because the event happened several days ago.

For Condition Stops Being True, the record must still not match the original filter. If it matches again, the run is cancelled. Missing or deleted records do not pass a condition or recurring-filter re-check.

Exit conditions

Trigger re-checking only re-evaluates the original trigger condition, and only when a Delay step finishes. Sometimes you need something broader: a way to stop a run early if any unrelated condition becomes true, checked continuously throughout the run, not just at delays.

That’s what an exit condition is for. It’s a single filter you set once for the whole workflow (separate from the trigger and from any individual step). Kanri checks it right before every step runs — not only after delays — and if the record matches, the run is cancelled immediately with no further steps executed.

For example, a reminder workflow could have an exit condition that matches a record no longer needing follow-up. Kanri checks it before the next step executes, including when a delay resumes. It does not interrupt an action already executing or continuously monitor a sleeping delay.

Exit conditions are optional — leave them unset and a run will only stop for the reasons covered above (reaching a step with no next step, a re-checked trigger condition no longer being true, or the workflow being disabled or deleted).

See Building in the Editor for how to set one up.

Running a workflow manually

You can also trigger a workflow manually, in two ways:

From the Workflows page — open a published workflow and use Test Run to start it against a specific record. The workflow can be disabled; testing still runs the published version.
From lists and reports — published, enabled workflows with a Manual trigger appear in matching record action menus. Staff need the permissions required by that workflow, not necessarily workflow administration access.

See Run a Workflow Manually for details.

Test runs execute real actions. Messages are sent and changes are saved, so use test records. For Membership and Subscription workflows, choose a Member first, then choose one of that Member’s records.

Next steps

Create Your First Workflow — a hands-on tutorial
Triggers — all the ways a workflow can start
Steps — what a workflow can do