Custom flows — overview

Use a custom flow when you want to package a piece of your own business logic — fraud screening, third-party enrichment, extra approval gating — and have IntelliAuth run it as a reusable unit inside your sign-in or sign-up path.

System flows vs custom flows

Your tenant already has system flows: Login, Registration, Password Reset, MFA Enrolment, and a few others. They exist the moment the tenant is provisioned. Each one has a fixed start and a fixed end — the platform locks the steps that validate credentials and create sessions — but you can insert your own blocks into the stages between those milestones.

A custom flow is different. You create it from scratch. It has no built-in milestones; every stage and every block is yours to define. You give it a name and a slug, build it in the same visual builder, publish it, and then embed it inside a system flow using the Run custom flow block. When a user signs in and reaches that block, your custom flow runs as a sub-routine, then hands control back to the system flow.

The two complement each other. A system flow is the spine of the authentication event; a custom flow is a module you drop into that spine wherever your business logic belongs.

Login system flow
  ├─ Stage: Pre-Login (locked)
  │   └─ Block: Password Check
  ├─ Stage: Post-Auth
  │   ├─ Block: Risk Evaluate
  │   └─ Block: Run custom flow  ──────────────────────────────────┐
  │                                                                  │
  │             your-fraud-screening custom flow (runs here)        │
  │             ├─ Stage: Signal collection                         │
  │             │   └─ Block: IP reputation                         │
  │             ├─ Stage: Decision                                  │
  │             │   └─ Block: Condition                             │
  │             └─ Stage: Terminal                                  │
  │                 └─ Block: Allow  (or Deny)                      │
  │                                                                 │
  │   ◀── continues here when custom flow returns Allow            │
  └─ Stage: Post-Login (locked)                                    ─┘
      └─ Block: Issue Session

The custom flow sees the in-flight user — who they are, what device they came from, what risk signals look like — and either allows the parent flow to continue or halts it with a deny.

When to reach for a custom flow

Reach for a custom flow rather than editing a system flow directly when any of the following is true:

The logic you're adding belongs in more than one system flow. A fraud-screening module embedded in both Login and Password Reset is one custom flow with two attachment points, not the same blocks duplicated in two editors.
You want to test, version, and publish the module independently of the system flow it will eventually slot into.
The logic is significant enough that naming it — "Cymmetri banking fraud gate" rather than "a bunch of blocks in Post-Auth" — helps your team understand what's running.
You're building toward a template that colleagues will reuse across multiple tenants.

If the logic is small and specific to one system flow, adding blocks directly to that system flow's stages is simpler.

What you can do in a custom flow (v1)

Custom flows in v1 support the same block catalogue you use in system-flow stages, with a few constraints:

Blocks that enrich, evaluate, decide, call webhooks, or run custom actions are all available.
Blocks that mint tokens or issue sessions are reserved for system flows. A custom flow cannot create a session on its own.
Nested custom flows can call webhooks, evaluate risk signals, condition on any flow state, and return allow or deny to the parent.

This is intentional. In v1, the platform is the only caller — your custom flow runs inside an existing system flow, inheriting its trust boundary. The block catalogue available in custom flows is a subset of what you see in system flows — anything that requires a session already in progress (like issuing or modifying one) is excluded. You can explore the palette directly in the builder.

What v1 does not yet include

Custom flows today are nested-only: the only way to invoke them is from a system flow via the Run custom flow block. You cannot call a custom flow directly from your own backend or from an SDK-integrated frontend — that surface lands in a later release.

This isn't a limitation to work around; it's the right starting point. Nesting your custom flow inside a system flow means the platform handles authentication context, session state, and the trust boundary on your behalf. You focus on the logic; the platform handles the plumbing.

When external invocation ships, you'll be able to take the same custom flow you built today and invoke it directly from your own backend — no rebuild required.

Terminology to know

System flow — a platform-provided flow (Login, Registration, Password Reset, etc.) that exists for every tenant and has locked milestones.
Custom flow — a flow you author from scratch; no locked milestones; publishable and embeddable in system flows.
Run custom flow block — the block you add to a system-flow stage that invokes a published custom flow at run time.
Nested execution — the custom flow runs inside the parent system flow's session; subject, device, and risk context are inherited.
Terminal allow / terminal deny — how a custom flow communicates its outcome back to the parent. Allow means the parent flow continues; deny means the parent flow halts.

Where to go next

Build your first custom flow — Author a custom flow walks you from the Create button to Publish.
Attach it to a system flow — Embed a custom flow in a system flow covers the Run custom flow block and explains how allow / deny and the time budget work.
Understand the underlying concepts — Flows concepts explains how flows, stages, and blocks fit together, which is the same model custom flows use.