Automation Version History and Rollback

Every automation keeps an immutable, partial version history of its execution configuration. Creating an automation and each configuration save normally records a version snapshot, and every run records a snapshot id for attribution. The portal surfaces the history and lets you restore any earlier version as the live configuration — so captured fields from a change that made things worse can be restored without reconstructing them by hand. Operational state and several consent-backed settings stay outside the snapshot; this page says exactly which.

Open it from the automation's detail page, or go straight to /automations/{id}/versions.

How versions are created

• Creating an automation records version 1.
• Every subsequent configuration save normally records a new version (+1). A change to fixture-recording consent alone is deliberately not versioned, because that consent is outside the snapshot; combining it with any captured configuration change still creates the version. There is no way to edit or delete a past version — the history is append-only.
• Restoring a version and deploying a staging copy both update the automation through the same versioned save path, so each appends a new snapshot rather than changing an old one.

The Advanced Builder's auto-saved local draft is browser storage, not a version. It becomes versioned only when you persist it with Deploy as Dry Run for a new automation or Save for an existing one. Test agent runs the saved version, not an unsaved local draft.

What a version captures

A version snapshots a defined subset of the automation's execution-shaping configuration. It is an audit and rollback record for the captured fields, not a complete replay package for everything that influenced a run:

What a version does not capture

A version is deliberately partial: it covers configuration, not operational state. These are never recorded, so a version-to-version comparison can say nothing about them and a restore leaves them alone:

• The automation's name and description
• Knowledge sources
• Consent and destructive-consent state
• MCP harness exposure (whether the automation is exposed to your AI assistant)
• Webhook payload mode and the example payload
• Memory opt-in
• Fixture-recording consent
• Queued-run patience (how long a queued run waits before it is skipped)
• The production require passing checks before deploy gate
• Failure-notification settings
• Support-ticket toggles
• Active/paused state

This matters when you are reconstructing why a past run behaved as it did. The version is authoritative for the values in its captured columns, but it does not preserve the effective composed prompt. That prompt can include uncaptured knowledge sources and other composition performed when the remote agent is synchronized. A knowledge-source change therefore does not appear in version history, and the snapshot alone cannot reproduce the complete context Anthropic saw.

Versions and runs

• Every run records a version id. That gives durable attribution for the snapshot's captured subset; it is not proof of the effective knowledge, composed prompt, remote-agent state, credentials, effective deny-list expansion, shared MCP-client state, or other uncaptured runtime inputs.
• An immediately launched run normally records the latest version. There is no user-facing way to select an older snapshot for a new run.
• A queued run can be hybrid. Its version id is fixed when the trigger is enqueued. When a slot frees, launch keeps that id but reloads the current automation definition and remote resource ids. Checks that explicitly read the retained version — such as pinned policy checks — use its captured fields, while other launch and runtime inputs come from the current definition, live catalog, credentials, and shared MCP client.
• Crash recovery has the same attribution boundary. It keeps the original run's version id but starts a fresh execution from the current live automation definition and current remote resource ids. Treat the version id as captured-field attribution, not proof that a queued or replacement attempt reconstructed every other input from the earlier state.

Each run detail header shows its shortened snapshot id, exposes the full id on hover, and links back to Version history. The adjacent partial audit attribution label is deliberate: use the mapping for captured fields, not as a claim that every execution input was frozen.

The version history table

The page lists every version newest-first. Each row shows:

• Version — the sequential version number; the newest carries a Current badge.
• Created — when the version was recorded (UTC).
• Trigger — the trigger type captured in that version (on-demand / scheduled / webhook).
• Model — the AI model captured in that snapshot. A later queued or recovered execution can retain this snapshot id while loading the automation's current model at launch.
• Mode — whether that version was in Dry-run (connector writes simulated) or Live.

The current version shows "In use" instead of a button. Every older version has a Restore button.

What changed between two versions

Every version except the oldest also has a What changed button, which expands an inline comparison against the version immediately before it. Nothing is fetched — the comparison runs over the snapshots already on the page, so it opens instantly.

• Settings (model, reasoning effort, trigger type, max runtime, max credits per run, max tool-result size, dry-run mode, supervision, and run-as identity, which is labelled audit-only) read as old → new. The captured concurrent-run setting and production approval policy are not among the compared rows — both are snapshotted and both are re-applied on restore, but a change to either is invisible here, so check them on the automation itself. Queued-run patience is in neither category: it is not snapshotted at all, so a rollback leaves it exactly as it is now — see What restore does not touch.
• Outbound network access reads as old → new when the choice moved. The allowed-host list is compared only when both versions use Only the hosts I list, and the package-manager switch only when both use one of the two narrow choices — a stored list is not in force under any other choice (under Unrestricted and Platform default the registries are reachable anyway), so comparing it there would report hosts the version could never have reached. A version saved before the setting existed reads as not recorded rather than as a change.
• Long text — the system prompt and the trigger configuration — is reported as changed, with a Show old and new fold that prints both in full.
• Callable, required, chained, native, pre-run, and post-run tools appear as changed settings or + added / − removed lists. A deny-list policy compares its exclusions instead, and a switch between allow-list and deny-list mode is called out on its own line.
• If nothing the snapshot captures moved, the expansion says exactly that: "Nothing the version snapshot captures changed."

Every expansion ends with a "Not covered by version snapshots" line, because a snapshot is deliberately partial and a silent "no change" would otherwise read as a guarantee it cannot make. Changes to these never show in a comparison:

Knowledge sources · Consent / destructive-consent state · MCP harness exposure (ExposeAsMcpTool) · Payload mode & sample payload · Memory opt-in · Failure notifications · Support-ticket toggles · Active/paused state

That printed line is shorter than the full uncaptured set. Fixture-recording consent, queued-run patience, and the production require-passing-checks-before-deploy gate are also outside the snapshot, and a change to any of them likewise never shows in a comparison — they are simply not named on the line. The What restore does not touch section below lists everything.

Treat Nothing the version snapshot captures changed as a result over the captured fields listed above, not proof that every stored or operational input was identical.

Restoring a version

Click Restore on the version you want, then confirm — the portal asks before a restore rewrites the live configuration. The defining property: restore is itself an edit that appends a new version. It never rewrites or deletes history, so the rollback is auditable and the captured states remain available for later restores. Fields outside snapshots — and the preserve-on-null rules below — set the limits of that reversibility.

Restore:

• Re-applies the restorable snapshot fields as the current configuration — the saved base system prompt, model and reasoning effort, connector-tool configuration and policy, required/denied tools, tool chains, pre-run and post-run tool steps, native Anthropic tools, outbound network access (the choice, the host list, and the package-manager switch), trigger type and trigger config, max runtime and max credits per run, max tool-result size, live approval in test runs, concurrent-run setting, production approval policy, and dry-run flag revert to captured values, subject to the preserve-on-null rule below.
  • An allow-list restores its stored fixed selection. A deny-list snapshot records exclusions, not a timeless exact allow-list: the effective callable set is expanded against the live entitled and credentialed catalog.
  • If the snapshot had a tool enabled that you've since turned off, restoring turns it back on. Review the restored configuration if you disabled a capability after the snapshot was taken.
  • Restoring a different network choice replaces the automation's execution environment. It applies to sessions that start after the restore; a run already under way keeps the environment it started in, so a restore that narrows the network does not narrow that run. Review the restored choice and host list before you rely on it.
  • Restoring the production approval policy does not make production runs pause; production pausing is not available yet.
• Records the restore as a brand-new version. Nothing in history is edited or deleted. The restored state becomes the newest version and the one you rolled back from stays in history, so you can restore that later snapshot too, subject to the same snapshot limits. The new version is attributed to you (the member who performed the restore) — or to the StackJack staff member, when a restore is done on your behalf from the admin console — the same way an edit is.
• Re-validates and re-syncs the automation exactly as a normal save does: catalog re-validation, an Anthropic/MCP re-sync that rewrites the shared per-automation MCP client's AllowedTools and IsDryRun values, a new version snapshot, and schedule reconciliation from the automation's current active state. This is a real edit, not a metadata swap.
• Is never refused because a run is in flight. No run state blocks a restore. What protects an active run is narrower than a refusal: it keeps the immutable version row it pinned when it launched, and restore only ever appends versions, so a concurrent restore cannot corrupt that run's own snapshot. The shared per-automation MCP client is a different matter — its AllowedTools and IsDryRun are rewritten immediately, and the gateway re-reads both on every tool call. A live run therefore picks up the restored callable surface and dry-run posture on its next connector call. Wait for active runs to finish, or interrupt them, before restoring a materially different callable surface or a different dry-run posture.
• Is scoped to the automation. A version id from a different automation is treated as "not found" — you can only restore a snapshot that belongs to this automation. Archived automations cannot be restored.

You'll get a success toast naming the version you restored, and the table reloads with your rollback as the new current version.

The comparison is narrower than the restore. The What changed view does not include the captured concurrent-run setting or the production approval policy. Both are restored from the snapshot, so a rollback can change either one without the comparison saying so. Review them on the automation itself after a restore, along with everything named in the view's Not covered by version snapshots line.

Undoing a staging deploy

Production already has an immutable current snapshot before a staging copy is deployed. The deploy appends the staged configuration as a new production version. To undo its captured fields, open production version history and Restore the version immediately before the deploy.

Neither creating a staging copy nor deploying one is refused because a run is in flight. The refusals that do exist are about structure and readiness: you cannot stage a staging copy, an automation can have only one live copy at a time (deploy or discard it first), a copy that has never been provisioned cannot be deployed (re-sync it, then test it), and a production automation that requires passing checks refuses a deploy whose evaluations are not green — that last one can be overridden with a reason, which is audited. Because a deploy rewrites production's shared MCP client exactly as an ordinary save does, finish or interrupt production's active runs before deploying.

The Lifecycle audit section also shows Deployed without passing checks decisions. It records the actor, time, server refusal report, optional reason, and final outcome—including an override that was authorized and audited but whose deployment later failed.

What restore does not touch

Two separate categories survive a rollback untouched.

Fields the snapshot never captured — everything listed under What a version does not capture — are not guessed from history and stay at their current values. If you also need to revert any of them, edit it directly after restoring.

One field the snapshot does capture is still never re-applied: the run-as identity. Versions record which member an automation ran as, for audit, but restore keeps the current binding — silently reverting who an automation acts as would be a security hazard, so that change must remain deliberate.

MCP harness exposure remains exactly as it is, regardless of the trigger type being restored: exposure to your AI assistant is no longer tied to the trigger type, so a rollback to a scheduled or webhook version no longer clears it. See Triggers and execution guarantees.

Snapshots taken before tool policy, tool chains, native tools, bookends, outbound network access, or max tool-result size were captured may have no value for those fields. Restore preserves the current value rather than guessing. For outbound network access that rule is the safe direction: applying a blank setting from an older snapshot would return a configured automation to the platform default and remove outbound access it needs, as a side effect of restoring something unrelated. One important current gap follows from that safety rule: restoring a no-limit snapshot does not remove a max tool-result ceiling introduced later, including by staging deploy. Clear that ceiling directly in the builder if you need to remove it.

Restoring a version also restores its pre-run and post-run steps, decision steps included, and its trigger configuration, including any smart filter on a webhook trigger. Both can start costing money again on the next run, so review them after a rollback the same way you review a re-enabled tool.

Restore re-syncs the remote agent after applying the captured fields. Its effective system prompt is recomposed from the restored base prompt and captured governance plus the current knowledge sources, because historical knowledge and the final composed prompt are not part of the version snapshot. Restore therefore cannot reconstruct an old effective composed prompt from the version row alone.

Related pages

• Editing an Automation
• The Automation Detail Page
• Run Lifecycle and Statuses