History
When a workflow breaks in production, you need to know what changed and who changed it. History gives you a full revision trail so you can audit changes, understand intent and roll back fast.
What You Get
- Revision timeline with timestamps
- Author visibility for each change
- Revision names and descriptions
- Restore capability for any prior revision
When Revisions Are Created
Scout creates a new revision each time you deploy a workflow to an environment. Changes you make in the Console are saved as drafts until you deploy. Once deployed, that snapshot becomes a named revision in History.
Revision Workflow
- Make changes and test in Console
- Name the revision clearly before deploying
- Add a short description of what changed and why
- Deploy to your target environment
The name and description travel with the revision, so future you (and your teammates) will know what that version was for.
Naming Guidelines
Good revision names explain the intent, not just which block changed.
| Good | Avoid |
|---|---|
Add fallback path for CRM timeout | updated blocks |
Cap token usage on summarizer | fix |
Route EU users to compliant model | v2 |
Good descriptions add the why:
“Fallback returns cached response if CRM is down. Prevents 503s during peak hours.”
Restore and Rollback
If a deployment causes issues, you can restore any prior revision without rebuilding from scratch.
- Open History in your workflow
- Find the last known good revision
- Click Restore
Restoring creates a new revision based on the old one. It doesn’t overwrite your history, so you can always see what you reverted from. Once restored, deploy it to your target environment to make it live.
For a full rollback strategy across environments, see Environments.
Next Steps
- Environments: Deploy revisions safely across dev, staging and production
- Logs: Validate run quality after changes
- Console: Re-test restored revisions before redeploying
Built with ❤️ by Scout OS