A custom action runs in a Flow when you drop a Run Custom Action block into a Stage and save. This guide walks every step of that wiring, from opening the editor to confirming the action fired on a real request.
- You have a saved and enabled custom action. Disabled actions are skipped at runtime; enable them on Flows > Actions before wiring.
- You know which Flow you want to add it to — Login, Registration, Password Reset, or a custom Flow you created.
- You know which Stage is the right slot. If you are unsure, read Flows concepts for a primer on Stages and when each fires.
Step 1 — Open the Flow editor
Section titled “Step 1 — Open the Flow editor”From the sidebar, go to Flows and click the Flow you want to edit. On the Flow detail page, click Edit in the header. The Flow editor opens with the Stage canvas on the left and the block palette on the right.
/screenshots/admin.flows.custom_actions.attaching_to_pipelines/block-in-stage.png Step 2 — Drop a Run Custom Action block
Section titled “Step 2 — Drop a Run Custom Action block”In the block palette, find Run Custom Action under the Actions group. Drag it into the Stage where you want the action to run. The block appears as a tile in that Stage with the label "Run Custom Action" until you configure it.
You can also click Run Custom Action in the palette to append it to the end of the currently selected Stage.
Step 3 — Configure the block
Section titled “Step 3 — Configure the block”Click the block to open its configuration drawer. The key field is Action — a searchable dropdown that lists every saved action in your tenant. Actions that are disabled appear in the list with a "Disabled" badge and a warning that they will be skipped at runtime; you should enable them before saving the Flow.
/screenshots/admin.flows.custom_actions.attaching_to_pipelines/config-drawer.png Pick your action from the dropdown. The drawer also shows a link to Edit action once an action is selected — clicking it opens the action editor in a new tab so you can adjust the code without losing your Flow editor state.
Step 4 — Position the block in the Stage
Section titled “Step 4 — Position the block in the Stage”Blocks inside a Stage run top to bottom. If other blocks are already in the Stage, drag the Run Custom Action block above or below them to set the execution order. Blocks that run before yours write their outputs into step.<block-slug>.<field>, which your action can read; blocks that run after yours do not yet have outputs your action can see.
For example: if you want your action to read the result of a Risk Evaluate block, place the Run Custom Action block below Risk Evaluate in the same Stage, and reference step.risk-evaluate.score inside your action code.
Step 5 — Save the Flow
Section titled “Step 5 — Save the Flow”Click Save in the Flow editor header. For system Flows (Login, Registration, Password Reset, and so on), saving publishes the new layout immediately. There is no separate draft or publish step for the block layout change — the saved state is live.
Custom Flows that you created follow the same behaviour.
Step 6 — Verify the action fires
Section titled “Step 6 — Verify the action fires”To confirm the wiring is correct, trigger the Flow with a test identity. For the Login flow, open your tenant's login page — https://<tenant-slug>-<org-slug>.<your-domain>/login — and sign in with a test account. Then return to the Flow detail page and open Recent Runs. Click the latest run to see the execution trace. Your action's block should appear in the trace with whatever log entries and state writes it emitted.
If the block is missing from the trace, check that the action is enabled and that you saved the Flow after adding the block.
What happens when an action throws or denies
Section titled “What happens when an action throws or denies”Two outcomes stop the Flow:
- Unhandled error or timeout: the block reports the error; the Flow halts at that point. The run trace shows the block as failed with the error message. The event is logged in audit. The user sees a generic error page.
api.deny(reason): your action explicitly rejected the request. The Flow halts; the run trace shows adenyterminal;reasonis captured in audit. The user sees a generic error page. This is the intended path for blocking a login from a flagged identity or a prohibited IP range.
If you want the Flow to continue even when your action encounters an error, set On Error to Continue on error in the block's config drawer. This lets the Flow proceed to the next block without surfacing the error to the user.
Reordering and removing the block
Section titled “Reordering and removing the block”To reorder, drag the block to a new position within the Stage. To remove the block entirely, click it to open the config drawer and select Remove. Removing the block detaches it from this Flow; the action itself remains saved and can be re-attached at any time.
Attaching the same action to multiple Flows
Section titled “Attaching the same action to multiple Flows”One action can appear in as many Flows as its trigger type covers. Each attachment is independent: the position in the Stage, the on-error policy, and the execution mode (synchronous or fire-and-forget) are all per-block settings that do not affect other Flows that reference the same action. Cymmetri, for example, attaches their "tag corporate vs self-serve" action to both the Login flow and the Registration flow — the same action code runs in both, but the Login attachment is synchronous while the Registration attachment is asynchronous.
To add the action to a second Flow, repeat steps 1 through 5 for that Flow.
Disabling without detaching
Section titled “Disabling without detaching”If you want to temporarily stop an action from running without removing the block from the Flow, open the action on the Actions page and toggle it off. When the action is disabled, the Run Custom Action block is skipped silently — the Flow continues as if the block were not there. Re-enable the action to resume execution without touching the Flow layout.