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

A save that changes the graph bumps the workflow's revision and archives the previous one — see The workflow document. A change that touches only a workflow's metadata does not write a revision, so not every edit leaves something here to go back to. The audit log below records those edits either way.

Past revisions are listed on the workflow's History, newest first, with the version that runs now named as current. Selecting a revision draws its graph, read-only, in a preview beside the list, and selecting the current version flips back, so you can look at what the graph was then against what it is 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.

Four caveats, in the order they surprise people:

• A confirmed restore discards unsaved editor changes. Save or abandon your edits first.
• A restore re-applies the revision's triggers authoritatively. The trigger set goes back to what it was, which means a trigger that did not exist at that revision is removed — including one your integration currently depends on. Read the workflow's triggers before you restore, not after.
• The history draws a revision's graph, not everything a restore touches. The preview shows the graph, and the graph and its variables both come back. Execution mode does not — the current value stays.
• Runs are not rewritten. Runs produced by the later revision stay exactly as they are; a restore changes what happens next, not what happened.

Two things follow from that. Only a change to the graph writes a revision, so a trigger-only edit leaves nothing to roll back to — if a workflow broke because somebody changed a schedule, check the audit log for what actually changed rather than restoring an earlier graph. And because a restore is a save, a restored graph that fails validation leaves the workflow inactive, except a revision whose branches break the rules in What a save refuses: that restore is refused and nothing changes.

Deleting a workflow is permanent, and it takes more than the graph: its revision history and every one of its runs go with it, including the step history — along with its triggers, the missed runs still waiting to be replayed, and the state stored for that workflow alone, such as its sync cursors and correlation mappings. There is no undelete. The audit log entry recording the deletion survives.

The audit log

Changes to workflows, triggers, credentials, secrets and runs are recorded under Integration Studio → Audit Log, with the actor and the moment. The actor is taken from the sign-in token rather than a field the caller fills in, so it is not something a client can assert — but it is an opaque subject id, and you need your identity directory to turn it into a person. Entries the platform wrote itself carry no actor.

You do not have to read it on a screen. The Integration Studio API exposes the audit log as an endpoint, scoped to the caller's own organisation and tenant, so you can pull it on a schedule. That matters most when an AI assistant is driving the studio — see What an AI agent can change.

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.
• A retention window, and no bulk export. Rows are pruned after a year by default, and that default is not a contractual commitment. As with run history, do not treat the log as a compliance archive — pull it on a schedule and keep your own.
• No record of reads. The log records changes. That someone — or something — listed your credentials or read a run's payloads is not recorded anywhere.
• 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.