Workflows

A workflow gives a record type a lifecycle: a set of states (Draft, In review, Approved…) and the transitions allowed between them. Records move through the workflow one transition at a time — by a button click or automatically — so a campaign can’t be “Launched” without passing “Ready”, and everyone can see where things stand at a glance.

Creating a workflow

1. Open Admin → Workflows and click + New workflow — just a name and the record type it applies to.
2. The visual canvas editor opens: add states as boxes, drag them into place, and draw transitions as arrows between them.
3. Select any state or transition to edit its properties in the side panel — name, color, conditions, and what happens when it fires.

Each state gets a color; that color follows the record everywhere — on the record page, in lists, in reports.

Manual and automatic transitions

Every transition is either:

• Manual — it appears as a button on the record for users with edit rights. “Approve”, “Cancel”, “Mark paid”.
• Automatic — it fires by itself when its event occurs: when a record is created, updated, or when a specific field changes. Use it to start every new application in “Received”, or to move a payment to “Confirmed” when its amount is filled.

A transition can also set field values as it fires, and even trigger an integration job.

The Start transition

A transition drawn from the Start marker puts a record into its first state. Make it automatic on creation and every new record enters the workflow immediately — or leave it manual and a Start button appears on records that haven’t entered yet (also available in bulk from the list).

Guards — conditions on transitions

A guard is a condition a record must meet for the transition to be available — built with the same filter editor used everywhere (field values, relationships, ”= me”). Examples:

• “Approve” only when amount is filled and reviewer is set.
• “Publish” only for events that have a date in the future.

Guarded transitions simply don’t show their button until the record qualifies.

Transition screens — collect fields on the way

A transition can open a screen: a small dialog collecting a few fields before the transition completes. You configure it by pointing the transition at a form — the form’s fields (and their required flags) become the dialog. A “Reject” transition can demand a rejection reason; a “Confirm attendance” can ask for the number of guests. The values are saved with the state change, together, in the record’s history.

Transition screens work everywhere the transition does — the record page, bulk transitions from the list (fill once, apply to all), and even portals.

The state on records, lists and reports

• The record page shows the current state as a colored pill, next to the transition buttons currently available.
• The state is a first-class field for reports: filter by it, group by it (“campaigns by state”), show it as a list column — always with its label and color.
• The state itself is only changed by transitions — never typed — so the lifecycle is always trustworthy.

Multiple workflows per type

A record type can carry several independent workflows — say, an editorial lifecycle and a payment lifecycle on the same record. Each keeps its own state, its own pill and its own buttons. Deactivate a workflow at any time without losing its history.