Who changed this Jira field, and when?
For a change made on an issue, Jira tells you directly: open the issue, read its history, and the field, the old value, the new value and the person are all there. For a change made to the configuration itself, the answer lives in the admin audit log instead, and it is thinner. You get an entry saying a field context or a workflow was edited, by whom, at what time. What you do not get is the part you actually needed, which is why. The request that caused the change happened somewhere else, in a ticket or a chat or a corridor, and Jira never saw it.
That gap is what makes the question expensive. Finding the change takes minutes. Reconstructing the decision behind it takes an afternoon of asking people what they remember.
Key takeaways
- Field changes on an issue are in that issue’s history; changes to Jira configuration are in the admin audit log, which is a separate place with less detail.
- Both records tell you what changed and who did it. Neither records why, because the request that prompted the change was never in Jira.
- JAMEs keeps every event it handles for thirty days, and each one is attached to the plan a person approved, so the reason travels with the change.
- JAMEs Premium adds search across that history, spanning people and conversations, which turns tracing a change into a query rather than an investigation.
- None of this covers a change made by hand in the Jira admin screens. That one is in Jira’s audit log and nowhere else.
Why is finding the change the easy half?
Because the log was designed to prove an action happened, not to explain it. An audit entry is built for the question a compliance review asks, which is whether anyone touched a thing they should not have. It answers that well. The question an administrator asks three months later is a different one: this field has a validator on it that is now blocking half the service desk, and before removing it, somebody would like to know what it was put there for.
That reason was never written down in Jira. It was in the request, and requests live wherever your organisation keeps them. So the trail runs cold at exactly the moment it gets useful, and the search moves to Slack, to email, and to whoever has been there longest.
Where does Jira itself record a configuration change?
In the audit log, under system administration, which is distinct from the history you see on an issue. It captures administrative activity across the site: schemes, permissions, users, projects and the rest. Retention depends on your plan, and on Cloud the window on the free tier is short enough that a question asked a quarter later may find nothing at all.
It is worth knowing the shape of what it stores. Entries are terse by design, typically naming the object, the actor and the timestamp, and sometimes the old and new values. Reading one tells you a change occurred. Reading fifty, which is what a real investigation involves, tells you a change occurred fifty times and gives you no way to sort the deliberate from the incidental.
What does JAMEs record about a change it made?
The plan it was asked to carry out, and the approval that released it. Nothing reaches a Jira site through JAMEs without a person reading a proposal and accepting it first, so every change it applies already has a stated intention attached. That is not an extra logging feature. It falls out of the approval gate, and it is the reason the record is more useful than an audit entry: the why was captured at the moment it existed, rather than reconstructed later.
Those events are kept for thirty days on every tier, and they are there to be read back. JAMEs Premium extends the retention and adds search over the whole history, spanning users and conversations, so a change found in Jira can be walked back to the request that produced it. On a site with more than one administrator, that is usually the shortest path from noticing something odd to understanding it.
Automation rules work a little differently, because JAMEs does not write to them. It keeps a change log for each rule, a comparison against the previous version, and the ability to export any earlier version. Restoring one is an administrator’s step, taken with that exported file. JAMEs supplies the evidence and the file; the person does the import.
Which changes does this never account for?
Every change that did not go through JAMEs. Somebody editing a field configuration directly in the Jira admin screens leaves an entry in Jira’s audit log and leaves nothing in JAMEs, because JAMEs was not involved and has no view of the site except through the work it is asked to do. The same is true of changes made by other apps, by scripts, and by the Jira REST API.
This matters for how you read the two records together. JAMEs answers who changed this and why for the subset of changes it made. Jira’s audit log answers who changed this for everything, with less detail and no reason. Neither is a full account on its own, and a tool claiming to give you one would be describing something it cannot see.
The honest version of the promise is narrower and more useful: the more configuration work runs through an approval step, the larger the share of your change history arrives with its reasoning intact.
Frequently asked questions
How long does Jira keep its audit log?
Can JAMEs tell me who changed a field if the change was made by hand?
Is the search across history available on every tier?
Can JAMEs undo a configuration change once I have traced it?
If tracing configuration changes has become a regular part of someone’s week, that is usually a sign the requests and the changes live in different systems. Viter does that untangling as Jira and JSM automation work, and hello@viter.io reaches us either way.