A comparison explains how two workflow states differ. A restore changes desired or runtime state, so understand the direction before confirming it.
Choose the comparison that answers your question
- Version to version: what changed between two recorded workflow versions?
- Environment to environment: why is Production behind or different from Staging?
- Desired to runtime: what caused a drift finding?
Semantic and raw differences
A semantic comparison highlights meaningful workflow elements such as nodes, connections, settings, or references. A raw comparison shows the underlying serialized definition. Use semantic comparison for review and raw comparison when exact evidence is required.
Before restoring
- Confirm the selected workflow and environment.
- Confirm which version will become authoritative.
- Review changes made since that version.
- Check whether an incident response or emergency edit is still in progress.
- Confirm credential references remain valid.
- Record the reason and approver.
Restore desired state versus accept runtime
Restore desired state treats the recorded desired version as correct and brings the runtime back toward it. Accept runtime treats the runtime change as intentional and starts the process of making that state authoritative.
Do not accept runtime simply to clear an alert. Do not restore desired state until you know the runtime difference is unwanted. Both actions can overwrite useful changes if used without investigation.
Verify the result
After a restore or acceptance operation, confirm the resulting version, review the audit event, validate expected executions, and make sure the drift finding closes for the reason you intended.