Opening any custom Action — from the Actions list, or from "edit Action" on a flow slot — takes you to the Action editor. Full-screen; TypeScript-aware; built for medium-scale authoring inside the admin console.
Layout
Section titled “Layout”The screen has four panes:
- Code editor (left, biggest). TypeScript / JavaScript editor with syntax highlighting, auto-complete, type-checking against the platform's Action SDK types.
- Metadata panel (top right). Name, slug, version, compatible triggers, config schema.
- Test harness (bottom right, tab). Synthetic inputs + Run button + the last test run's output.
- Run history (bottom right, second tab). The last N real-flow runs of this Action with their inputs, outputs, durations, logs.
TypeScript awareness
Section titled “TypeScript awareness”The editor auto-imports types from @intelliauth/action-sdk (the platform's runtime contract). Auto-complete works for:
event— the read-only context object (event.user.*,event.request.*,event.client.*,event.tenant.*, and so on).api— the side-effect object (api.access.deny(),api.accessToken.setCustomClaim(),api.fetch(), and so on).Logger—console.logand structured logging.
Type errors highlight in real time. Save is blocked if there are unresolved errors (with a force-save override if you really know what you're doing).
The {} Variables picker is available next to any text field in the editor — URLs, headers, body templates, and Decision block expressions. Click it to browse event.* paths grouped by category (user, request, transaction, client, tenant, authentication), step outputs from upstream blocks, and session fields. The picker inserts the reference for you; you don't have to remember the exact path.
Metadata panel
Section titled “Metadata panel”The fields here are what attach-time + audit-log + runtime depend on. Treat them carefully:
- Slug — immutable. The platform tracks attached Actions by slug + version, so changing slug = orphaning attached flows.
- Version — semver. The platform auto-bumps the patch on save; you override to bump minor or major when changes warrant.
- Compatible triggers — defines which trigger slots this Action can be attached to. Picking too narrowly limits flexibility; picking too broadly lets admins attach the Action in places where it doesn't make sense.
- Config schema — a JSON Schema describing the form admins fill when attaching. The editor has a visual schema-builder + a raw-JSON view.
Test harness
Section titled “Test harness”Click the Test tab. Fill in:
- Trigger — pick which trigger you're simulating.
- Synthetic input — JSON for the StepInput. The form has reasonable defaults for each trigger.
- Synthetic config — what the tenant admin would have filled in when attaching.
Click Run. The harness runs your code in a sandbox identical to production. Results appear across four tabs:
- Console — all
console.log/console.erroroutput from your action. - State — the shared state map as it stood after your action ran (any writes via
api.stepState.set()appear here). - API calls — outbound HTTP calls your action made via
api.fetch(), with URL, status, and latency. - Result — the final outcome (allow / deny / redirect / demand-mfa) and any error or stack trace.
The test harness doesn't touch real data. Run as many tests as you want; no audit-log noise. For a step-by-step guide to the Test pane see Test a custom action.
Run history
Section titled “Run history”Once the Action is attached to a flow and the flow has run, the run history populates. Each entry:
- Run ID — unique per execution.
- Triggered by — the flow + sign-in / signup event.
- Outcome — continue / block / demand-mfa / redirect / error.
- Duration — how long the Action took.
- Logs — captured stdout / stderr.
Click any entry for the full per-run view, including the exact input + output. This is where you go when a user reports "I'm getting blocked at sign-in" — find their attempt, see what the Action saw.
Edit + save + publish
Section titled “Edit + save + publish”Edit the code. The editor marks changes with a dirty indicator. Save the Action — the version bumps.
Save publishes the new version but doesn't change attached flows. Flows pinned to v0.2.0 keep running v0.2.0 until you update their pin.
Save and update attached flows (a button next to Save) publishes the new version AND updates every flow attached to the old version to use the new one. Use carefully — this rolls out across production immediately. The save records flow.action_published + multiple flow.action_updated audit entries.
Side-by-side diff
Section titled “Side-by-side diff”Open the editor for an Action with multiple versions; there's a Compare versions button. Pick two versions; see the diff. Useful for "what changed between v0.1.0 and v0.2.0 of this Action?" especially during incident review.
Source-control your Actions
Section titled “Source-control your Actions”For Actions you maintain long-term, prefer source-control over the in-console editor:
- Author locally in your editor.
- Commit to a git repo.
- Use the CLI (
@intelliauth/action-cli) to upload to the tenant on every release.
The in-console editor is great for quick iteration; the CLI + git pattern is great for stability + reviewability. Many teams mix — use the console for quick fixes, source-control for substantive changes.
What's NOT in the editor
Section titled “What's NOT in the editor”- Multi-file projects. The editor handles a single
index.ts; for anything bigger, use the CLI / upload-as-package path. - Direct module installs. Actions can only depend on what the platform's runtime SDK provides — a small, curated standard library. Adding arbitrary npm packages isn't supported.
- Debugging across executions. No "break here next time this Action runs" mode. The test harness is the debugging surface; run history is the post-mortem surface.