Recipes are complete, working Flow configurations for a specific goal. Each one tells you exactly which Flows and Stages are involved, what the custom-action code looks like, how to verify it worked, and what to watch out for. Take a recipe as a starting point — copy the blocks and code, adapt the constants to your tenant, and you have a live, tested behaviour in under an hour. Combine two recipes if your goal is a combination of two problems.
How to use this page
Section titled “How to use this page”Scan the groups below to find the problem that matches yours. Each recipe entry names the goal and the blocks involved. Open the linked page for the full walkthrough, including the code and a step-by-step configuration guide. Nothing here assumes a particular skill level — the prerequisites are the same for every recipe: you have the Flows editor open and at least one tenant provisioned.
Onboarding
Section titled “Onboarding”First impressions matter. These recipes shape what happens in the moments after a user creates an account — whether that is blocking low-quality signups, personalising the experience from day one, or routing different user segments to different onboarding paths.
- Block disposable emails — Deny registrations from known temporary email providers before the account is created. Blocks: Run Custom Action (Pre-Create stage of Registration).
- Welcome new users — Send a welcome email and write signup context to app_metadata immediately after a new account is created. Blocks: Run Custom Action (Post-Create stage of Registration).
- Tag corporate vs self-serve — Infer whether the new user belongs to an enterprise customer or a self-serve trial based on their email domain, and tag them in app_metadata so downstream flows and your application can branch on it. Blocks: Run Custom Action (Post-Create stage of Registration).
Security and fraud
Section titled “Security and fraud”These recipes let you express risk-aware policies without writing a full custom identity service. The platform surfaces IP intelligence, VPN and Tor signals, and a composite risk score at every login — these recipes turn that data into decisions.
- Step up MFA on risk — Challenge returning users for a second factor only when the login looks anomalous. Blocks: Risk Evaluate, Decision, MFA (all in the Post-Auth stage of Login).
- Deny Tor and VPN logins — Reject login attempts originating from Tor exit nodes or known commercial VPN ranges. Blocks: Run Custom Action (Post-Auth stage of Login).
- Geo-mismatch step-up — Require re-authentication when a user logs in from a country that does not match their historical location. Blocks: Run Custom Action + Decision + MFA (Post-Auth stage of Login).
Claims and personalisation
Section titled “Claims and personalisation”Access tokens carry what you put in them. These recipes write the right data into the right claim so your application never needs to make a back-channel call to look up a user's plan, region, or department.
- Inject tier into JWT — Read
app_metadata.tier(set at signup by the tagging recipe) and embed it as a custom claim on every access token. Blocks: Run Custom Action (Post-Login stage of Login). - Track session duration — Write the session start timestamp into app_metadata so reports and downstream analytics can compute session-length distributions. Blocks: Run Custom Action (Post-Login stage of Login).
Integrations
Section titled “Integrations”These recipes wire the platform to services outside it — your CRM, your mailer, your Slack channel, or a fraud-signal API. Each one follows the same pattern: the custom action reads event context, shapes a payload, and calls api.fetch to deliver it.
- Fraud webhook branch — POST to a fraud-signal API and deny or allow based on the response score. Blocks: Run Custom Action (Post-Auth stage of Login).
- Sync new user to CRM — POST enriched user data to your CRM endpoint immediately after account creation. Blocks: Run Custom Action (Post-Create stage of Registration).
Auth methods
Section titled “Auth methods”These recipes replace or augment the default password-based Login flow with an alternative credential type.
- Passwordless via magic link — Replace the password check with an email magic link dispatched by the platform. Blocks: Send Channel OTP, Verify Channel OTP (Pre-Login stage of Login).
What is NOT a recipe
Section titled “What is NOT a recipe”Some problems are faster to solve elsewhere.
Single-field configuration changes — adjusting session lifetime, turning MFA on or off for the entire tenant, setting the lockout threshold — are covered in the block reference for each block type. No walkthrough needed; the field has inline help.
Standalone custom-action snippets that you want to copy without a full Flow configuration walkthrough belong in the Custom action examples page. Go there if you just want a code pattern without the surrounding steps.
Questions about how Flows work at all — what a Stage is, what state namespaces exist, when to use a Block versus an Action — belong on the Concepts page. Start there if the vocabulary in these recipes is new.
Suggesting a recipe
Section titled “Suggesting a recipe”If you have a use case that is not covered here, reach out through the support channel in your admin console. Include the goal in one sentence and the blocks or API surface you think would be involved — that framing makes it straightforward to add.