Skip to main content
Once your SuperFlow is built, the editor gives you everything you need to check it, deploy it, test it, watch it execute, debug failures, manage in-flight runs, handle human approvals, and share the SuperFlow with teammates. This page walks through each.

​
Check, save, and deploy

A SuperFlow has a draft and, once you deploy one, a live version. Your edits save to the draft, and Run in the editor always runs the draft. Webhooks, schedules, API calls, and Execute Workflow nodes that call this SuperFlow run the live version. Until you deploy a version, they run the draft, so a SuperFlow keeps working as before until you deploy for the first time.

​
Check the SuperFlow

Select Check in the toolbar to find problems before you run or deploy. The badge on Check shows how many problems it found. The panel lists two kinds of findings:
  • Problems stop the SuperFlow from running or make a node certain to fail, for example a required setting that is missing or a setting with an invalid value.
  • Items to check still run, but probably not as intended, for example a setting the node ignores.
Each finding names the node and the setting involved. Check uses the same validation as the API, so the codes it shows match the validation reference.

​
Save

SuperFlow saves your edits to the draft a few seconds after each change. Select Save in the toolbar to save them right away.

​
Save a version and deploy it

Select Deploy in the toolbar to open the deploy panel. The top of the panel shows which version is live, for example Live: v1.
  1. Optionally, describe the changes in the version.
  2. Select Save version to save the current draft as the next numbered version. Save version is unavailable while the canvas has unsaved edits, and the panel shows No changes since the last version when there is nothing new to save.
  3. Under Versions, select Deploy next to the version you want production to run, and confirm.
Saving a version never changes what production runs. Only deploying does. To look at a version without deploying it, select View. To roll back, deploy an older version: for a version older than the live one, the button reads Roll back. Saving and deploying a version need edit access.

​
Testing a run

Click the Run button in the top-right toolbar of the editor (tooltip Run SuperFlow) to open the execution panel. In the panel:
  • Type your input in the Simple mode text area, or toggle to JSON mode (link at the top right of the input area) to send a structured payload as raw JSON.
  • If your Trigger expects a file, either because the trigger mode is File Upload, or because a document node downstream expects one, the input area shows a drag-and-drop file picker and the run button reads Upload & Run.
  • Click Run to submit. The button changes to Running… while the SuperFlow is executing.

​
Live monitoring

While a SuperFlow runs, status is shown in two places. On the canvas: every node displays its live state:
  • Amber pulse: currently executing.
  • Green check: completed successfully.
  • Red ×: errored.
  • Blue pause: awaiting a human approval.
The edges between nodes animate while data flows along them, so you can see the run’s progress at a glance. In the execution panel: each node has an expandable card that fills in as the node completes. Click a card to see the node’s JSON output. Output-style nodes (those that produce final results) are expanded automatically.

​
Lifecycle controls

For long-running SuperFlows, you can intervene from the execution panel. All three controls are backed by durable state: they survive service restarts and behave consistently even under concurrent operator action.
  • Pause: request a cooperative pause. The run pauses at the next boundary between nodes (it won’t interrupt a node mid-execution). Paused runs stay paused even across restarts.
  • Resume: continue a paused run from where it stopped. Completed nodes stay completed; the next pending node starts fresh.
  • Terminate: cancel the run outright. Any in-flight work is stopped, and the run is marked as cancelled. Cancellation is final.
A run can be paused and resumed unlimited times without losing data. While paused, the run consumes essentially no resources.

​
Retries on failure

Every retryable node can be configured to automatically retry on transient failures. In a node’s configuration drawer, expand the Retry section and toggle Retry on failure on. Then set:
  • Max attempts: how many times the engine will retry before declaring the node failed.
  • Wait between attempts: backoff delay in milliseconds.
Retries are themselves durable. If the service restarts mid-backoff, the engine remembers exactly how many attempts have been made and resumes the retry sequence from the correct count, so you never accidentally end up with more attempts than configured. When the max-attempt count is exceeded, the node fails permanently and the entire run errors out. The failed run shows up in History with the failing node and its error preserved, so you can diagnose and re-run. For more on the durability properties that back retries, pauses, and the rest of the engine, see Reliability & durable execution.

​
Execution history

Click the History button in the toolbar to open the history drawer on the right side of the canvas. The drawer has two tabs:
  • Executions: past runs of this SuperFlow, with their status, trigger source, and timestamps.
  • Approvals: pending approval requests waiting for a human decision (see below).
Click any past run to replay it on the canvas:
  • Every node shows the status it had during that run.
  • Clicking a node opens its output drawer with the JSON it emitted in that specific run.
  • Re-run from a specific node if you want to retry only the failed tail of a previous run. A re-run uses the current draft, so you can fix a node in the editor and retry it against the earlier run’s data.
History is the fastest way to debug a failed run: you can see exactly which node failed, what it received, and what it tried to do.

​
Human-in-the-loop approvals

When a SuperFlow reaches a Wait for Approval node, the run pauses durably and waits for a person to act. While paused:
  • The run’s status changes to “Awaiting approval”.
  • The node shows the blue pause indicator on the canvas.
  • A new entry appears in the Approvals tab of the history drawer, including the configured approval message (with any expressions resolved against the live data) and the approval form if one is configured.
  • Anyone with access to the SuperFlow can review the request.
The approver has two choices:
  • Approve: the run continues down the node’s Output 0 path. Any approval form values the approver submitted flow downstream merged into the item.
  • Reject: the run continues down the node’s Output 1 path, also carrying the submitted form values (plus a rejection_reason alias). You typically connect this output to a “send rejection email” or “mark as denied” chain.

​
Approval forms

A Wait for Approval node can ask the approver for structured input alongside the decision, not only an Approve / Reject button. Useful when the approver needs to supply context that the rest of the workflow depends on: a category, a reviewer note, a signed PDF attachment. Configure the form schema on the node itself (see Approval forms in the node reference for the full field options). When the run pauses, the approver sees the form alongside Approve / Reject; submitting either decision validates the fields you marked required for that decision, then merges the values into the downstream item. File fields specifically: when an approver uploads a file, it lands on the downstream item as a file item the next node can send, parse, or display. The wait costs nothing. Paused runs sit in durable storage, not in a hot-running process. A SuperFlow can wait minutes, hours, days, or weeks for a human without consuming a thread or holding memory. Service restarts during a paused-awaiting-approval state are invisible to the workflow: the moment a human responds, the run resumes from exactly the same point. Approvals don’t time out automatically. They sit pending until acted on, unless your SuperFlow uses a parallel Wait node to enforce a deadline. This makes Wait for Approval safe for slow-moving processes: onboarding flows that wait on customer action, escalation paths that wait on managers, anything you’d normally need a separate ticketing system to track.

​
Sharing a SuperFlow

By default, only the user who created a SuperFlow can see it. To collaborate, share it with teammates. From the SuperFlow list page (or from the editor toolbar), click the Share button on a SuperFlow you own. A modal opens listing your organization members:
  • Tick the teammates you want to share with.
  • Confirm.
Shared collaborators can:
  • View the SuperFlow and its execution history.
  • Edit nodes and configuration.
  • Run the SuperFlow manually or trigger its schedules.
Only the owner can:
  • Delete the SuperFlow.
  • Change who it’s shared with.
Re-opening the Share modal at any time lets you add or remove people. Removing everyone returns the SuperFlow to a private state.

​
Lock a SuperFlow

The owner can lock a SuperFlow from the … menu in the editor toolbar. While it is locked, collaborators can still view and run it, but they cannot save changes, save a version, or deploy. The owner can still edit, save versions, and deploy, and only the owner can lock or unlock it.

​
Where to go from here