Revisions and audit

Two separate records answer "what changed": the workflow's own revision history, which holds the graph as it was at each save, and the audit log, which holds who did what across the studio.

Revisions

Every save bumps the workflow's revision and archives the previous one — see The workflow document.

Past revisions are listed on the workflow's History, newest first, with the version that runs now named as current. Selecting an older revision draws it beside the list, so you can compare what the graph looked like then against what it looks like now.

Restoring one

Restore puts an earlier revision back, after asking. Restoring is itself a save: it produces a new current revision rather than rewinding the numbering, and it queues a new build like any other save.

Three caveats, in the order they surprise people:

• A confirmed restore discards unsaved editor changes. Save or abandon your edits first.
• The history shows a revision's graph, not everything about the workflow. Trigger configuration, variables and the execution mode a revision carried are not part of what you are looking at, and not part of what comes back.
• Runs are not rewritten. Runs produced by the later revision stay exactly as they are; a restore changes what happens next, not what happened.

The second caveat is the load-bearing one. If a workflow broke because somebody changed a variable or a schedule, restoring an earlier graph will not fix it — check the audit log for what actually changed before you restore.

Deleting a workflow deletes its revision history permanently. There is no undelete.

The audit log

Changes to workflows, triggers, credentials, secrets and runs are recorded under Integration Studio → Audit Log, with the actor and the moment.

That is the record for the questions that come up in a customer conversation:

• Who deactivated the trigger, and when?
• Was the credential re-authorized before or after the failures started?
• Did somebody terminate that run, or did it fail on its own?
• When was the secret last overwritten?

For secrets, note what is and is not there: that a secret was written is recorded, and the value never is — the store never returns a value to anyone. See Secrets.

What the trail does not give you

• No per-role attribution beyond the actor. Authorization inside the studio is not role-based yet, so the log tells you who acted, not what permission let them.
• No retention or export promise. As with run history, do not treat it as a compliance archive. If you need one, keep your own.
• No diff between revisions. You can read two revisions side by side; nothing computes the difference for you.

Where to go next

• The workflow document — what a revision is a snapshot of.
• Runs — the record of what a revision did while it was current.
• Credentials — the four positions a credential reports, which the log records transitions between.