How a process runs

When you deploy a process, you make a contract: for every piece of work that arrives, the platform will execute these steps, in this order, under these conditions, and tell me what happened. This page is about what’s behind that contract — how the platform actually runs the thing.

You don’t need to know any of this to use Superprocess. You absolutely need to know it the day a process behaves in a way you didn’t expect.

A process run's states, from trigger to completion

Definition vs. instance

A process definition is the diagram you build in the designer. It’s a template — a description of what should happen, with no actual work attached. You deploy a process definition.

A process instance is one execution of that definition. Each time a trigger fires, a new instance is created from the deployed definition. Instances run concurrently and independently: a hundred invoices can be in flight at once, each with its own state, each running through the same definition.

This distinction matters because changes you make to the definition don’t affect instances that are already running (more on that under Versioning below).

Triggers

A process instance starts when its trigger fires. The trigger is part of the process definition — it’s a configurable property of the start event. The platform supports several trigger types:

• Event triggers. An external event matches a pattern: an email arrives in a specific mailbox, a webhook is hit, a file appears in a watched folder.
• Scheduled triggers. A clock-based schedule: every weekday at 9 AM, the first of the month, every 15 minutes.
• Manual triggers. A person clicks a button or makes an API call to start a run with explicit input.
• Process triggers. Another process completes a step that starts a new instance of this one (chaining).

When a trigger fires, the runtime allocates an instance, attaches the trigger’s input data as the instance’s starting variables, and begins executing steps from the start event.

Variables and state

Every process instance carries variables — named values that travel with the instance from step to step. A new variable is created when a step produces an output (the AI agent emits amount, the integration returns po_status). Once written, a variable is readable by every subsequent step.

Variables are typed. Each step declares what it consumes and produces. The platform enforces the types at design time (you can’t wire a string into a step expecting a decimal) and at runtime (a corrupted value won’t propagate).

The state of an instance is the combination of its current position in the diagram, its variable values, and any pending external events (a signal it’s waiting for, a timer ticking down). The runtime serialises this state to durable storage after every step — so if a worker crashes mid-flight, a different worker picks up exactly where it left off.

Gateways and branching

A gateway is how a process makes decisions. The most common type is an exclusive gateway: evaluate a condition expression against the instance’s variables, and follow whichever outgoing branch matches.

amount < 10000 && po_matched == true

The condition above evaluates two variables. At runtime, the platform substitutes their current values, computes the boolean, and routes the instance accordingly. If no branch’s condition matches, the default branch is taken; if there’s no default and nothing matches, the instance fails.

Other gateway types handle parallel execution (do two things at once and wait for both), event-based routing (whichever signal arrives first wins), and inclusive branching (take all matching branches).

When the branching logic is really a table of rules — credit tier by amount and region, routing by ticket category — you don’t have to encode it as a chain of gateway conditions. A business rule task can evaluate a DMN Decision and write the result back into a variable that a downstream gateway then routes on. This keeps complex rules legible and auditable instead of buried in gateway expressions.

Versioning

When you redeploy a process, the new definition becomes version N+1. The old definition stays around. Behaviour:

• In-flight instances continue running under the version they started on. An invoice that started before the redeploy finishes on the old version’s diagram, with the old version’s agent config and integration bindings.
• New triggers create instances under the latest version.

This is sometimes called version pinning. The reason: changing a process mid-execution is a recipe for surprises — an in-flight instance might find a step that no longer exists, or a variable name that changed type. Pinning keeps history coherent.

Long-lived instances

Some processes run for days or weeks (a vendor onboarding flow that waits for a contract to be signed, an annual compliance review). Those instances stay on their original version for the duration. If you change the definition substantially, expect to see old-version instances finishing for as long as the longest one takes.

Durability and recovery

The platform guarantees that once a process instance starts, it runs to completion — or fails explicitly. It doesn’t silently stall. Three sources of non-determinism are handled automatically:

• Worker crashes. If the worker running an instance dies (deploy, OOM, hardware failure), another worker resumes the instance from its last serialised state. The reader sees a brief pause; no work is lost or repeated.
• Integration failures. Calls to external systems can fail (network blip, rate limit, brief outage). The runtime retries with exponential backoff. If retries are exhausted, the step fails and the instance is marked Failed in Workflow Executions for human follow-up.
• Agent failures. AI model calls can time out, return malformed output, or error. The runtime retries up to the agent’s configured retry count. If retries are exhausted, the agent step is marked Failed — same as an integration failure.

What the platform does not guarantee:

• Step idempotency. If an integration call succeeds on the third retry but the first two also reached the remote system, you’ve executed the call three times. Either the remote system is idempotent (most are — invoice numbers, PO IDs), or you design around it.
• Cross-process consistency. Two concurrent process instances might both try to update the same external record. The platform doesn’t lock; consistency is the remote system’s job.

When things go wrong

Workflow Executions surfaces failed runs. Each one shows the failing step, the error message, the variables at the point of failure, and the full timeline of what happened before. Two recovery options:

• Retry the failed step. The runtime re-executes from the point of failure with the same inputs. Use when the cause was transient.
• Replay from start. Discard the failed instance and start a new one with the same input. Use when the input is fine but something earlier in the run set up a bad state.

Most failures get resolved by automatic retries before reaching the executions screen. The manual options are for the residual cases.

Try it

Running and monitoringWorkflow Executions, run details, retries and replays in practice.

Designing the processPutting triggers, gateways, and tasks together in the designer.

Look up

BPMN paletteEvery element the designer supports, with semantics.

ConfigurationRuntime tunables like retry policies and timeouts.