Automation Version Rollback

Version rollback restores any previous version snapshot as an automation's live configuration. It is available in the portal on every automation's Version history page (/automations/{id}/versions) — each older version has a Restore button.

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 compatibility rules below—set the limits of that reversibility.

What restore re-applies

Restore copies the snapshot's captured fields onto the live automation:

• Saved base system prompt
• Model, and the model's reasoning effort
• Connector-tool configuration and policy. An allow-list restores its stored fixed selection; a deny-list restores exclusions and is expanded against the live entitled and credentialed catalog rather than acting as an exact historical allow-list.
• Advanced tool policy (required/denied) and tool chains
• Pre-run and post-run tool steps
• Native Anthropic tools (Web Search / Web Fetch / Code Execution)
• Outbound network access — the choice, the host list, and the package-manager switch
• Trigger type and trigger configuration
• Max runtime (seconds) and max credits per run
• Max tool-result size
• Live approval in test runs
• Concurrent-run setting
• Production approval policy
• Dry-run flag

Because restore re-applies the snapshot's tool policy, tool chains, bookends (decision steps included), trigger configuration (any smart filter included), and native-tool settings, rolling back to a version that had a tool enabled re-enables that tool—review the restored configuration if you disabled a capability after the snapshot was taken. Production approval behavior still depends on a platform setting StackJack has not enabled; restoring the policy does not enable that feature.

Restoring a version whose outbound network access differs from today's replaces the automation's execution environment. Sessions that start after the restore run under the restored network choice. 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, in the same way you review the restored tool set.

Snapshots minted before tool policy, tool chains, native tools, bookends, outbound network access, or max tool-result size were captured can carry no value for them. Restore preserves the live value rather than guessing. That is the safe direction here: applying a blank network setting from an older snapshot would quietly return a configured automation to the platform default and remove the outbound access it needs. For max tool-result size, null is always handled this way: a version with no ceiling cannot remove a ceiling added later. Clear the ceiling directly in the builder after restore when that is your intent.

It then runs the same tail as an ordinary save: 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 scheduler reconciliation based on the automation's current active state. During that re-sync, StackJack recomposes the effective system prompt from the restored base prompt and captured governance plus the automation's current, uncaptured knowledge sources. Restore therefore cannot reconstruct an old effective composed prompt from the version row alone.

Because that tail always appends, the restored state becomes the newest version and the automation you rolled back from stays in history. You can restore that later snapshot too, subject to the same partial-snapshot and preserve-on-null rules.

What restore deliberately leaves alone

Two separate categories survive a rollback untouched.

Fields the snapshot never captured are not guessed from history and stay at their current values:

• Name and description
• Webhook payload mode and the example payload
• Failure-notification settings, and the support-ticket toggles
• Knowledge sources
• Consent state
• Whether the automation is exposed to your AI assistant (expose-as-MCP-tool)
• Memory opt-in
• Fixture-recording consent
• The production require-passing-checks-before-deploy gate
• Active/paused state

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 is always deliberate.

Exposure to your AI assistant is no longer tied to the trigger type: every trigger type can be exposed, so a rollback to a scheduled or webhook version no longer clears the flag. See Triggers and execution guarantees.

Safety and attribution

• In-flight runs are not fenced. No run state refuses a restore. The protection an active run does get is narrower: it pinned an immutable version row at launch and restore only ever appends versions, so a concurrent restore cannot corrupt that run's own configuration snapshot. The shared per-automation MCP client is rewritten immediately, though — AllowedTools and IsDryRun both — and the gateway re-reads them on every tool call, so a live run picks up the restored callable surface and dry-run posture on its next connector call. Wait for it to finish, or interrupt it, before restoring a materially different callable surface.
• Attribution. The new version records the member who performed the restore (or the StackJack staff member, when a restore is done on your behalf from the admin console), the same way an ordinary edit is attributed.
• 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.
• Confirmation required. The portal asks you to confirm before a restore rewrites the live configuration.
• The comparison is narrower than the restore. The Portal's What changed view does not include the captured concurrent-run setting or the production approval policy. Both are restored from the snapshot — they are simply absent from the compared rows, 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 section.

Related pages

• Automation Versions (Audit History)
• Automation Version History and Rollback (the UI walkthrough)
• Run Lifecycle and Statuses