What History Provides
Revision timeline
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.
Author visibility
Each revision shows who deployed it, making it clear who to ask when you need context on a change.
Names and descriptions
Revisions carry a name and description you set at deploy time, so the timeline reads as intent rather than a wall of timestamps.
Restore capability
Restore any prior revision to roll back to a known good state. Restoring is non-destructive — your existing history stays intact.
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.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.
The Revision Workflow
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.
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.
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.
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.Open History in your workflow
Open the History panel in the workflow sidebar to see the full revision timeline.
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.
Click Restore
Select that revision and click Restore. Scout brings its configuration back as the current working state.
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.
Next Steps
Environments
Promote and roll back revisions across development, staging, and production for a complete rollback strategy.
Logs
Validate run quality after changes and confirm a rollback restored healthy behavior.
Running Workflows
Re-test a restored revision in the Console before you deploy it.