SPHIOR Atlassian Partner

Direct answer first: yes, with one condition — that somebody actually reads the history. And I should be straight that I don't have Hugo's or Maria's sample. I work on the change-record side rather than running a large estate, so treat this as a hypothesis. Maria's point about approval steps decaying into rubber stamps is…

You listed four things you'd want before delegating — audit history, only approved choices, rollback, approval. Context for where I'm coming from: I spend my time on Jira configuration change records, which is why audit history is the one item on that list I'd push back on. The audit log tells you that something was…

That's a better system than most of what I've seen, and the part I'd steal is the version number in the workflow name. It puts the version where you cannot miss it — in the UI, at the moment you're about to edit — instead of in a log you have to remember to go and read. The service desk request is doing something the Jira…

The Mover case is the right one to build the argument on — Joiners and Leavers are events, and Movers are a state change that nobody gets a notification about. One thing your architecture handles implicitly but is worth making explicit, because it's the part that tends to be missing when someone finally asks: HR system →…

Jonas's split — action system versus evidence system — is the right frame, and I'd add the property that decides whether something can be the evidence system at all. Evidence has to be harder to change than the thing it describes. If the approval lives on a JSM ticket, and the person who was approved can edit that ticket…

You clarified further down that the goal is documenting existing complexity to build a case for simplifying it. That changes the answer, and I think it changes it a lot. For a business case, documentation is the wrong artifact. Nobody approves a simplification project because a diagram was large. They approve it because of…

Gor's framing is right, and one practical thing on the second half of your question — the manual checking before you're comfortable pushing. Most of that time usually isn't verification. It's reconstruction. Somebody spent two weeks changing things in the sandbox, and now has to work out what they actually changed before…

Matteo's answer is good advice but it's answering a slightly different question — deactivating dormant accounts is licence hygiene, and you asked about auditing. Those overlap less than people expect. The thing that catches most teams out: an access review's evidence is not the list of who had access. It's the record that…

One thing neither answer mentions, and it is the first place I would look while you wait on Atlassian: there are two audit logs, and they are not the same log seen twice. You are almost certainly looking at the product-level one (Jira > Settings > System > Audit log). There is a second, separate log at admin.atlassian.com…

Solo dev to solo dev — this is a good build, and JRACLOUD-71967 sitting at ~1,000 votes since 2019 with no plans for another year or two is exactly the kind of gap worth filling. You asked what surfaces you might be missing. Four that aren't on your uncovered list and are easy to forget: JSM approvers configured as a…

The dead man's switch framing is right, and it works because a rule that runs leaves a trace you can miss the absence of. Worth naming the inverse case, though, because it lives next door and no heartbeat catches it: configuration changes. A permission scheme edit or a workflow draft publish happens once, succeeds, and…

This is old, but it still ranks, so here is where the three things you listed actually stand in 2026. "Audit logs show events without before/after states" — still true. The REST API schema does define changedFrom / changedTo per field, but the only documented example is a user's email address changing, and which event…

One thing worth adding, mostly so nobody reading later loses time on it: I would not count on support being able to recover audit records that have aged out of your retention window. Retention is a deletion, not an archive. It is worth asking, but plan as though the answer is no. There is one more place to look before you…

The first thing worth untangling here is that "180 days" belongs to only one of two different audit logs, and mixing them up is what makes this question hard to answer. The organization-level log (admin.atlassian.com > Insights > Audit log) is the one fixed at 180 days. It needs Atlassian Guard or an Enterprise plan, its…

Necro-posting since this thread still surfaces for the "backup before a workflow scheme change" question, and the underlying gap Harry's describing hasn't really gone away — just moved. This was Server/on-premise Jira in 2012 (XML export, full-instance backups only), but the same "no official way to snapshot just one…

Necro-posting because this thread still surfaces for the exact question, and Joe's answer is the core of the problem: there's genuinely no native way to see what a scheme looked like before you edited it, so "revert" isn't actually possible once the change is saved. The "spin up a fresh project/evaluation instance to see…

This is a rough one, and Arkadiusz's diagnostic steps are the right way to narrow down the cause. On the recovery side, I'd add one more angle: this kind of situation is exactly why "no magic restore button" is such a painful gap in Jira. Once a bulk change touches hundreds of tickets, there's no native way to see the…

"CONFIG CHANGED" in the audit log usually just means Jira detected a configuration change happened around that time (workflow, automation rule edit, etc.) — it's not itself an error state for your automation, more of a marker that something in the setup was touched. For the actual automation not firing, I'd check a few…

Following up since this is still open — Nic is right that the native logging doesn't go to that level of detail for plugin/app config changes specifically. The audit log will usually tell you *that* something changed and roughly when, but not a clean before/after diff of what actually changed within the plugin's config.…

Necro-posting this one because it still ranks well for anyone searching this exact question, and the underlying situation hasn't changed structurally: Jira Cloud (via Forge) still doesn't expose a native change-history event for permission scheme edits — Nic's answer above is still accurate. For anyone landing here now:…