We ran into a recurring Jira admin problem.
A workflow changes, something breaks, and then the difficult part begins — figuring out what exactly changed, when, and by whom.
The native Jira audit log is helpful, but for investigations I find it difficult to isolate workflow-related changes in a clean and readable way.
What I often want to answer quickly is:
• Who modified the workflow
• When it happened
• Which workflow was affected
• Export the history for review
I ended up building a small Forge app that filters the relevant audit records, resolves the IDs into readable names, supports filtering, and export. It also backfills 30 days and keeps 90 days of history.
Curious how other Jira admins handle this today.
Do you rely on the native audit log, change management process, or another tool?
If anyone wants to see what we built: https://marketplace.atlassian.com/apps/2538728805/workflow-changes-audit-for-jira
Hello and welcome @Alexander Stern _ Shern Consulting OÜ
in Jira Cloud, the native place to check this is the Audit log. That is usually the first step if you want to see who changed something and when.
It can help with workflow-related changes, but the weak point is usually not the tracking itself, but the readability. If someone wants a cleaner workflow-only history or easier comparison, the native view can feel limited.
Audit log is the standard and your app idea addresses a real gap beyond that.
Thanks @Arkadiusz Wroblewski — that matches what I’ve seen as well.
The audit log definitely has the data, but when investigating a specific problem (like a workflow change breaking something) it can be difficult to isolate just those events and quickly export them.
That was exactly the gap I was trying to address.
Out of curiosity — when you need to investigate workflow changes today, do you usually just rely on the audit log, or do you use any other tools or scripts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Alexander Stern _ Shern Consulting OÜ
In most cases I still start with the audit log, mainly to confirm that a workflow-related change actually happened and roughly when.
In my case the situation is relatively stable, because most workflow changes are handled by me directly. The reason is simply that others on the team usually do not have the same level of experience with Jira configuration, so we keep those changes centralized.
Because of that, investigations are usually easier, I already know what was changed or why. But if something unexpected happens, the audit log is still the first place I check.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Ho @Alexander Stern _ Shern Consulting OÜ ,
Thank you for your post.
In my opinion there isn't a "technical solution" but it is required to set a way to work, keeping trace of each change manually, like in a Confluence page describing each change with comments, date, what changed and son on.
Hope it helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Matteo Vecchiato ,
Thank you for the suggestion.
Yes, documenting changes in Confluence can work as a process, but in practice I often see workflow changes happening without being documented — especially in larger Jira instances with multiple admins.
That’s actually what motivated me to build the small app I mentioned: automatically capturing those workflow-related audit events and presenting them in a filterable history.
Out of curiosity — in the environments you’ve seen, do teams usually keep such Confluence pages consistently updated?
Alexander
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sometimes yes, it also depends on which debug level required and how much people understand the necessity.
I also consider that having an automatic audit is not sufficient anyway, you could have more details, but always you will dependent on people. So it is better to evangelize people about the necessity to trace adequately the changes
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Matteo,
That makes sense, and I’ve seen teams try to handle it with Confluence as well.
In practice though, I often notice that changes are not consistently documented — especially when multiple admins are involved or changes are made under time pressure.
That gap is actually what I was trying to solve: capturing those changes automatically so investigations don’t rely on manual tracking.
But yes, evangelizing people especially being able to make sure it happens. is a great thing to have in the workplace.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Quick update after trying this in a couple of environments:
What surprised me is how often workflow changes happen without anyone noticing — until something breaks.
The main thing that helped was having a clean, filtered history of workflow changes instead of digging through the full audit log.
Would be good to hear if you guys usually investigate only after something breaks, or have a way to track changes more proactively?
If helpful, this is what I built:
https://marketplace.atlassian.com/apps/2538728805/workflow-changes-audit-for-jira
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Another question — do people usually discover workflow changes only after something breaks, or do you actively monitor them?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One thing I'm considering adding next is notifications when workflows change (Slack/email).
Would that be useful for Jira admins here?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.