Self-Chain Detection(5.1.10)

This visual surfaces tickets where one actor made every status change the ticket recorded in a week, with two or more changes and no other account changing its status that week. On its own, it shows only who recorded the changes. Combined with a high hop count or a very short time span, it is a pattern a reviewer could ask about.

In many teams, status changes on the same ticket are spread across several people — someone picks it up, someone else reviews it, someone closes it. When one account records all of them, no second account appears in that ticket's status history for the week: that is the pattern a separation-of-duties review asks about first, and whether the reader's controls require a second person on that work is their determination.

What you can conclude

• A high hop count with a short time span (minutes) is the pattern a reviewer would ask about first: one actor moved the issue through several statuses within minutes, and no other account is recorded changing its status that week.
• Actors who appear repeatedly in this log across multiple weeks or issues are the ones a reviewer would ask about: who reviews their changes, and where is that recorded?
• An empty log means no ticket in the selected range had two or more status changes in one week all made by the same account.

How this chart works

Tabular log of issues where all status-transition events in a given week were triggered by the same single actor, with 2 or more transitions recorded. Columns: actor, issue key, hop count, time span (minutes between first and last transition), risk label. Distinct from the Missing Approval report — this log checks that the same actor drove every state change. Each row carries the actor's account type as Jira reports it (person, app, customer, unknown or erased); a self-chain by an app account is automation by Jira's own record and is shown apart from people's.