Flow builder

Click any flow from the Flows list. The builder opens. It's a visual editor: a top-down sequence of Stages, each Stage containing Blocks. (New to these terms? See Flows concepts.)

The layout

The login flow looks like:

┌─────────────────────────────────────┐
│ Stage: Pre-Login             [+ Add] │
│   Block: Identity Lookup             │
│   Block: Password Check              │
├─────────────────────────────────────┤
│ Stage: Post-Auth             [+ Add] │
│   Block: Risk Evaluate               │
│   Block: Run Custom Action    ⚙ ✕   │
│     └─ domain-allowlist              │
├─────────────────────────────────────┤
│ Stage: Post-Login            [+ Add] │
│   Block: Run Custom Action    ⚙ ✕   │
│     └─ slack-on-admin-signin         │
│   Block: Issue Session               │
└─────────────────────────────────────┘

Greyed-out blocks (Identity Lookup, Password Check, Issue Session) are non-editable platform steps. The Run Custom Action blocks are yours to configure or remove.

Adding a Block

Click + Add in a Stage. A panel slides open showing the block catalogue — grouped by family (Auth, Risk, Identity, Control Flow, Notification, Terminal). See Built-in blocks reference for what each block does.

To attach a custom Action, add a Run Custom Action block and pick one of your saved Actions (see Create an action). Click ⚙ on an existing block to configure it. Save.

Reordering Blocks within a Stage

Drag a Block up or down within its Stage. Blocks run in the order shown. Save.

A common ordering rule: cheap-and-blocking Blocks first (rate-limit, allowlist), then expensive Blocks (external API calls, decorations). If the cheap Block blocks, the expensive one never runs.

Configuring a Block

Each Block (and Run Custom Action) declares its own config schema. The configure panel shows the form. Common knobs:

Allowed domains — for the domain-allowlist Action, the list of permitted email domains.
Rate limit — for rate-limit Blocks, the requests-per-minute threshold.
Webhook URL — for Slack / CRM Actions, where to post.
Claim name + value template — for decoration Actions, what to add to the token.

Text fields support the {} picker — click the curly-braces icon to browse and insert event.* / step.<block>.* references without typing them by hand.

Test a flow

The builder has a Test button (top right). Click to simulate a run through this flow. See Test and publish for the full walkthrough; in brief:

You supply:

User email — pick from existing users or type one for hypothetical scenarios.
Request context — IP, user agent (for testing Blocks that depend on these).

The Test pane shows four tabs as the run progresses — Console (log output from custom actions), State (the shared state map after each Block), API calls (outbound calls your actions made), and Result (final outcome and any error). No real session is minted; it is purely diagnostic.

Use this before saving to confirm your new Block or Action logic is right.

Save + propagate

Save the flow. Changes apply immediately to the NEXT sign-in attempt against any application using this flow. Existing sessions are unaffected.

Each save records an audit-log entry with before/after state of the flow's Actions.

Disable a Block without removing it

Click the Block's ⚙ → toggle Enabled off. The Block stays in the Stage but is skipped on flow runs. Useful for temporarily disabling a flaky Action during incident response without losing its configuration.

Bypass for testing

In a development tenant, you may want to temporarily skip all custom Action blocks to test the platform's default behaviour. The flow's menu has Disable all actions in this flow — useful for "what does the system flow look like without my customisation?"

Common patterns

Domain-restrict pattern

Stage: Pre-Login. Block: Run Custom Action → domain-allowlist. Config: list of permitted domains. Effect: only allows sign-ins from emails in the list.

Risk-based step-up pattern

Stage: Post-Auth. Blocks: Risk Evaluate + Decision + MFA. Effect: if the risk engine scores the sign-in above threshold, the Decision block routes to MFA even if policy wouldn't normally require it.

Custom-claim decoration

Stage: Post-Login. Block: Run Custom Action → decorate-token. Config: claim name + value source (e.g., from event.user.app_metadata.tier). Effect: adds the claim to every issued access token.

Stage: Post-Create of the Registration flow. Block: Run Custom Action → webhook-emit. Config: URL + secret of your CRM webhook receiver. Effect: every successful signup notifies your CRM.