> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scoutos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Workflow History: Revision Timeline and Rollback

> Use Scout workflow history to audit revisions, understand what changed and why, and restore a previous revision to roll back a bad deployment safely.

History is the audit and rollback system for your workflows. It records a revision every time you deploy, captures who made the change and why, and lets you restore any prior revision without losing the ones that came after. When a deployment breaks something in production, History is how you understand what changed and recover quickly.

## What History Provides

<CardGroup cols={2}>
  <Card title="Revision timeline" icon="clock-rotate-left">
    Every deployment is recorded as a revision with a timestamp, so you can see the full sequence of changes over the life of the workflow.
  </Card>

  <Card title="Author visibility" icon="user">
    Each revision shows who deployed it, making it clear who to ask when you need context on a change.
  </Card>

  <Card title="Names and descriptions" icon="tag">
    Revisions carry a name and description you set at deploy time, so the timeline reads as intent rather than a wall of timestamps.
  </Card>

  <Card title="Restore capability" icon="rotate-left">
    Restore any prior revision to roll back to a known good state. Restoring is non-destructive — your existing history stays intact.
  </Card>
</CardGroup>

## When Revisions Are Created

A new revision is created when you **deploy** a workflow to an environment — not on every save. Changes you make and test in the Console remain drafts until you deploy them. At deploy time, Scout snapshots the workflow and records it as a named revision in History.

<Note>
  Because revisions are tied to deploys, the timeline reflects what actually shipped to an environment, not every intermediate edit. This keeps History focused on the changes that matter for auditing and rollback.
</Note>

## The Revision Workflow

<Steps>
  <Step title="Make changes and test in the Console">
    Build and iterate in Studio, then test your changes in the Console with realistic inputs until you're confident they behave correctly.
  </Step>

  <Step title="Name the revision">
    Before deploying, give the revision a clear name that explains the intent of the change. The name stays attached to the revision for future reference.
  </Step>

  <Step title="Add a description">
    Add a short description of what changed and why. This is the context your future self — or a teammate — will rely on when reviewing the timeline or deciding whether to roll back.
  </Step>

  <Step title="Deploy to your environment">
    Deploy to the target environment. Scout records the snapshot as a new revision, with its name, description, author, and timestamp.
  </Step>
</Steps>

## Naming Guidelines

A good revision name explains *intent* — what the change accomplishes — rather than which block you happened to edit. When you're rolling back under pressure, a clear name is the difference between an instant recovery and a guessing game.

| Good                                | Avoid            |
| ----------------------------------- | ---------------- |
| `Add fallback path for CRM timeout` | `updated blocks` |
| `Cap token usage on summarizer`     | `fix`            |
| `Route EU users to compliant model` | `v2`             |

## Writing Good Descriptions

Where the name captures *what*, the description captures *why*. A useful description explains the reasoning and the expected impact, for example:

> Fallback returns cached response if CRM is down. Prevents 503s during peak hours.

A description like this tells anyone reviewing the revision exactly why it exists and what problem it solves — invaluable when you're deciding whether a later change is safe to roll back to.

## Restoring a Previous Revision

If a deployment introduces a regression, restore the last known good revision to roll back.

<Steps>
  <Step title="Open History in your workflow">
    Open the **History** panel in the workflow sidebar to see the full revision timeline.
  </Step>

  <Step title="Find the last known good revision">
    Identify the revision that was running before the problematic deploy. Use the names, descriptions, and timestamps — and cross-reference Logs — to confirm it was producing correct output.
  </Step>

  <Step title="Click Restore">
    Select that revision and click **Restore**. Scout brings its configuration back as the current working state.
  </Step>

  <Step title="Deploy to make it live">
    Restoring updates your working state but does not change what's live. Deploy the restored revision to the target environment to make the rollback take effect.
  </Step>
</Steps>

<Note>
  Restoring is **non-destructive**. It creates a new revision based on the older one rather than overwriting anything, so the revisions you reverted from stay in the timeline. You can always see what you rolled back from — and roll forward again if needed.
</Note>

## Next Steps

<CardGroup cols={3}>
  <Card title="Environments" icon="layer-group" href="/workflows/environments">
    Promote and roll back revisions across development, staging, and production for a complete rollback strategy.
  </Card>

  <Card title="Logs" icon="magnifying-glass" href="/workflows/logs">
    Validate run quality after changes and confirm a rollback restored healthy behavior.
  </Card>

  <Card title="Running Workflows" icon="play" href="/workflows/running-workflows">
    Re-test a restored revision in the Console before you deploy it.
  </Card>
</CardGroup>