Datum
History & audit · Jira

How to see what a user changed in Jira

Updated October 6, 2026

Someone is leaving the team, or an issue took a wrong turn and you need to know who touched what. The question sounds simple — “show me everything this person changed in Jira” — and then you discover Jira has no single place that answers it. Here is why, and how to get a real per-user change trail.

What Jira shows you — and what it doesn’t

  • A user’s profile / “Worked on” surfaces recent activity for that person, but it is a short, recency-based feed, not an auditable record over a date range, and it thins out fast.
  • Each issue’s History tab shows the field changes on that one issue, with the author — but you would have to open every issue the person might have touched, across every project, and read each one by hand.
  • The admin audit log records administrative and security-relevant events (permission changes, config edits, some user events). It is not a per-issue field-change record, so it won’t tell you that this user moved 40 issues to Done or rewrote a customer field.

Put together: Jira can tell you about one issue’s changes, or recent activity, but not “every field this one person changed, across projects, between these dates.” That is exactly the view an audit or an offboarding needs.

The fix: a per-user change trail

Trailkeeper’s free tier gives a readable per-issue history; its paid tier adds a user-activity audit trail across projects, captured continuously so the question becomes a filter, not an archaeology dig:

  • Scoped to a person and a window — see everything one user changed in a date range, in one list.
  • Readable, not raw — status, priority and custom-field names resolved to text, old value → new value, rather than internal ids.
  • Exportable — hand a reviewer a CSV instead of screenshots (uncapped on paid) — see how to export Jira issue history to CSV.

It complements the admin audit log rather than replacing it: the audit log for who-administered-what, the change trail for who-edited-which-issues. For the related “who removed something” question, see how to find who deleted a Jira issue.

The takeaway

Jira answers “what changed on this issue” and “what did this person do lately” — but not “everything this user changed across projects, between these dates,” which is the one an auditor or an offboarding actually asks. Capture the field-change history with an audit-trail app and that becomes a filter-by-user-and-export, not a week of opening issues. If you’re weighing the two native surfaces first, Jira audit log vs issue history lays out which does what.

Frequently asked questions

Can I see everything a user changed in Jira?
Not easily. A user's profile shows recent activity, and each issue's history shows its own changes, but there is no native cross-project report of every field one person changed over a date range. The admin audit log covers config and some security events, not per-issue field edits by user.
How do I audit one user's changes for offboarding or an incident?
You need a per-user change trail across projects — who changed what, when, and from which value to which. An audit-trail app records this as changes happen, so you can filter by that user and date range and export the result.
Does Jira's audit log show issue field changes by user?
The admin audit log focuses on administrative and security events, not a full per-issue field-change record. For "what did this person change on issues", you need the issue change history captured and made searchable by user.
Can I export a user's activity from Jira?
Natively, not as a clean per-user change report. With an audit app you filter the captured history to one user and export it to CSV for a reviewer or an offboarding record.

← All Datum guides