Actor Bypass Fingerprint(3.1.10)

Every bypass event carries the account that recorded it. This visual identifies which specific accounts are responsible for the most bypass events — the transitions that skipped workflow steps or took paths the workflow does not define. It combines bypass count and reopen contribution into a single risk score per actor.

Where events cannot be attributed to a known actor, they cannot be reconstructed after the fact. A DORA or NIS2 reviewer asking "who made this change?" would have no answer for these events. This visual names the account behind each bypass event, which is the first thing such a reviewer asks for.

What you can conclude

• An actor at the top of this list with a high bypass count is worth a conversation about how the workflow is used — what does the workflow allow, and what does the team understand it to allow?
• For an account Jira reports as an app appearing high on this list, a reviewer could ask which automated process recorded those transitions and whether the workflow is meant to allow them.
• A broad distribution of bypass events across many actors points to how the workflow is designed rather than to any one person.

How this chart works

Horizontal bar chart ranking actors by risk contribution score (bypass events × weight + reopen contribution × weight), with a supporting donut chart showing bypass event share. Account IDs are shown by default; display names require additional configuration. Each actor is labeled with the type of account Jira reports for it (person, app, customer, unknown or erased). An action Jira records under a person's account counts as that person's, even when a tool acted on their behalf.