Does Jira log who changed a workflow or permission scheme?

Jira Cloud's native audit log (Settings > System > Audit log) records many configuration events with the actor and a timestamp, so it can usually tell you that a workflow or scheme was changed and by whom. What it generally doesn't capture is the before/after detail of what changed.

How do I see the before and after of a configuration change in Jira?

The native audit log records the event but not the difference between states. To see exact before and after values, you need to snapshot and diff the configuration over time, either manually or with a dedicated audit app such as Config Audit for Jira.

How long does Jira keep configuration audit history?

Native audit log retention is limited, which is a problem for compliance frameworks that expect a longer evidence window. A purpose-built tool keeps a continuous, retained history independent of the native log.

Can I export Jira configuration changes for a SOC 2 or ISO 27001 audit?

Not cleanly from the native log. Config Audit for Jira exports changes to CSV, a printable HTML report, or a SOC 2 / ISO 27001 evidence report that groups changes under the controls they evidence.

Does tracking configuration changes require admin access?

Yes. Viewing the native audit log requires Jira or site administrator permission, and any tool that reads administrative configuration is gated behind the same Jira administrator permission.

How to see who changed a Jira workflow, scheme, or field

A workflow or permission scheme changes, something breaks, and then the hard part begins: figuring out what changed, when, and who did it. Here's what Jira Cloud's native tools can and can't tell you — and how to get a clean before/after history.

By Larchmont Labs · Updated June 2026

The problem

If you administer Jira Cloud, you've lived this: a project's workflow, a permission scheme, or a custom field gets edited, and a week later something behaves differently. Approvals stop routing, a field disappears from a screen, or someone loses access. You know something in the configuration changed — but reconstructing exactly what, and tracing it to a person and a date, is slow and often impossible.

What Jira's native audit log actually shows

Jira Cloud does have a built-in audit log. As a site or Jira administrator, you'll find it under Settings (gear) → System → Audit log. It records many key administrative events — including a range of configuration changes — and stamps each with the actor and a timestamp. For answering "did an admin touch this area, and roughly when?" it's genuinely useful, and it's the right first place to look.

Where the native audit log falls short

The gap shows up the moment you need detail. The native log tends to record that an object changed — "workflow scheme updated," "permission scheme updated" — without the before and after values, so you can see a change happened but not what it actually was. On top of that, history retention is limited, filtering down to just configuration changes is awkward, and exporting a clean, review-ready record is clunky. A Jira admin summed it up well in the Atlassian Community:

The only place to see these changes is the admin audit log, which records the event but not the difference — the before and after states. — Jira administrator, Atlassian Community

That "before and after" gap is the whole problem. For an incident review or a compliance audit, "the permission scheme was updated by Jane on the 3rd" isn't enough; you need "the Browse Projects permission was changed from Any logged-in user to Project role: Developers."

Question	Native audit log	Purpose-built audit trail
Did a config object change, and when?	Yes	Yes
Who made the change?	Usually	Yes
Exact before → after values	No	Yes
Filter to configuration changes only	Limited	Yes
Long-term, retained history	Limited	Yes
One-click export for SOC 2 / ISO evidence	No	Yes

How to get true before/after history

A few approaches people use, in increasing order of reliability:

Manual exports or screenshots. Periodically capture your scheme and workflow configuration. It works in theory, but it doesn't scale, has no attribution, and nobody keeps it up.
A Confluence documentation page per project. A common suggestion — document the intended configuration and update it on every change. In practice it drifts the moment someone makes a change without updating the doc, and it still doesn't tell you who changed what.
A purpose-built audit app that snapshots your configuration on a schedule, diffs each snapshot, and records every change with the administrator, timestamp, and exact before → after. This is the only approach that's automatic, attributable, and audit-ready.

Config Audit for Jira Runs on Atlassian

We built Config Audit for Jira for exactly this gap. It takes a daily snapshot of your Jira administration — custom fields, permission schemes, notification schemes, workflow schemes, screens, issue-type schemes, and project roles — diffs each day, and records every change with who made it, when, and the exact before → after. You can search and filter by type, actor, change kind, or date, drill into the full history of any object, and export to CSV, a printable HTML report, or a one-click SOC 2 / ISO 27001 evidence report.

It's read-only, runs entirely on Atlassian Forge (your data never leaves your instance), and there's a 30-day free trial.

Try Config Audit free on the Marketplace See how it works →

FAQ

Does Jira log who changed a workflow or permission scheme?: Jira Cloud's native audit log (Settings → System → Audit log) records many configuration events with the actor and a timestamp, so it can usually tell you that a workflow or scheme was changed and by whom. What it generally doesn't capture is the before/after detail of what changed.
How do I see the before and after of a configuration change in Jira?: The native audit log records the event but not the difference between states. To see exact before → after values, you need to snapshot and diff the configuration over time — either manually or with a dedicated audit app such as Config Audit for Jira.
How long does Jira keep configuration audit history?: Native audit log retention is limited, which is a problem for compliance frameworks that expect a longer evidence window. A purpose-built tool keeps a continuous, retained history independent of the native log.
Can I export Jira configuration changes for a SOC 2 or ISO 27001 audit?: Not cleanly from the native log. Config Audit for Jira exports changes to CSV, a printable HTML report, or a SOC 2 / ISO 27001 evidence report that groups changes under the controls they evidence.
Does tracking configuration changes require admin access?: Yes. Viewing the native audit log requires Jira or site administrator permission, and any tool that reads administrative configuration is gated behind the same Jira administrator permission.