Workflows that survive
anything you throw at them

It means the workflow state is captured after every step rather than only held in memory while the workflow is running. If the host running the workflow crashes, gets restarted, or loses power, a healthy host picks up the workflow from the last completed step and continues from there. The user does nothing, the workflow does not need to know recovery happened, and no in flight work is lost beyond the single step that was running when the host died.

Retry policies can be set at three levels, per step, per integration, and per workflow, with each level overriding the broader one. The policy controls the maximum attempts, the maximum elapsed time before giving up, the initial backoff, the rate at which it grows, and the error categories that retry versus fail fast. Default policies apply automatically, and the per step override appears in the node configuration panel.

Every run keeps a complete record of everything that happened: the trigger that started the workflow, every step that ran, the inputs each step received, the outputs produced, the timing of every operation, every retry with its outcome, every decision made at conditional nodes, and the final result. The history is structured rather than free text, so you can search by field, filter by status, and export runs for compliance.

The durable engine scales horizontally by adding capacity as volume grows. Workflow state lives in the durable store independent of any host, so additional hosts can pick up new work without coordinating with the existing fleet. The engine handles load balancing, work distribution, and host health checks automatically, which means going from a hundred runs a day to ten thousand to a million is a provisioning change, not an architectural one.

Replay reconstructs exactly what happened in a previous run using the captured inputs and recorded decisions, useful for debugging issues deterministically. Re running fires a new workflow with the same inputs but with current state in the rest of the world, current data, configuration, and third party behaviour, useful for testing how an updated workflow handles the same kind of event. Both are one click in the execution history view.

Local fallback activates automatically if the durable execution engine becomes temporarily unreachable, for example during a maintenance window or a regional network event. Workflows continue on local execution so the business does not stop, every step still gets captured for the history to reconcile when the engine returns, and workflows switch back to durable on the next step. The team never has to intervene, and the audit trail stays complete.