One question comes up surprisingly often when working with a mature Jira Service Management environment:
“Why did this ticket change?”
Not what changed. That part is usually easy to find.
The difficult part is understanding what happened around the change.
For example:
A P1 incident is assigned to the correct support team.
A few minutes later, it moves to another team.
The customer asks:
“Why?”
You check the issue history and find the assignment changed.
Now the investigation begins.
Was it:
- A workflow transition?
- An automation rule?
- Another field change that triggered an automation?
- An integration?
- A scheduled rule?
- A user action?
- An AI agent?
This becomes particularly interesting in larger JSM environments.
A customer may have dozens or hundreds of automation rules, multiple integrations, complex workflows, and increasingly AI-driven processes interacting with the same issue.
The more automation we introduce, the more important understanding the context behind a change becomes.
A question for Solution Partners
When you're implementing or supporting JSM for a customer, how do you currently investigate these situations?
Do you rely on:
Issue history → Automation audit logs → Workflow configuration → Integration logs → Manual investigation
Or have you built something that gives administrators the context in one place which can be easily searchable as and when required ?
We've been exploring this problem while building Change Context for Jira.
The idea is simple:
Don't just show that something changed. Help explain the context around the change.
For Solution Partners, I think this could be particularly relevant to JSM governance, automation troubleshooting and ongoing managed services.
Disclosure: I'm part of the team building Change Context for Jira.
