Ticket - Jumping queues

[Placid Cardoz]

Has anyone found a reliable way to pull metrics around how many times a ticket has jumped from queue to queue. The goal is to find tickets that are bouncing between queues because no one know who can resolve it. 

There is a history of the ticket that indicates every time it was re-assigned but the data is empty when pulled in sheets. 

Other ideas? 

[Trudy Claspill]

Hello @Placid Cardoz 

Welcome to the Atlassian community.

Queues are based on Filters, so it really depends on what the filters are and how they differ from each other.

You used the phrase "re-assigned". Are your Queue filters based entirely on the Assignee of the ticket?

You said "the data is empty when pulled into sheets". What method are you using to pull the data?

Are you using Atlassian Analytics, or a third party app for reporting, or ...?

[Placid Cardoz]

Thanks, Trudy, for your response.

We assign tickets to queues and then a queue member assigns the ticket to themselves. Looking to determine every time this queue changes from one queue to another. 

Under the Project space there is Sheets that i use to get a holistic view of the tickets my team is assigned. So, I use that to try and pull history activity. 

Just using Sheets as mentioned above to get the raw data and then export to excel to see if i can find the data point I need. 

Also open to other ways to doing this. 

[Trudy Claspill]

Thank you for the additional information @Placid Cardoz 

What are your filters for your queues? That information is needed for us to recommend possible solutions.

[Khrystyna_Dzhus_SaaSJet_]

Hey @Placid Cardoz,

Jira stores this data in the changelog, but as you may have noticed, it is not available through standard data exports. Therefore, attempts to analyze “queue bouncing” in Sheets usually do not yield meaningful results.

For this specific use case (when tickets jump between queues), it is most effective to use ready-made reports that aggregate these transitions.

If you are open to apps, Time in Status (developed by my team) provides a Time in Assignee report that can help with this. It shows how long a work item was assigned to specific people within the report period; totals show combined assignee time, so you can quickly spot cases where:
👉 a ticket had multiple assignees
👉 ownership kept shifting between teams

Although it does not directly show the number of reassignments, it provides a clear picture of how work is allocated, which is a strong signal of “queue bouncing”.

If you’d like to learn more about transition models, you can also check out:

• Transition Count report to see how often tasks move between workflow statuses
• Status Count report to see how many times a work item has been in each status

Together, these reports allow to significantly simplify the detection of tickets that were re-assigned.

[Birkan Yildiz _OBSS_]

Hey @Placid Cardoz 

Native Jira tracks these changes in the issue history, but as you've experienced, exporting that granular transition data into spreadsheets usually results in empty or unparseable columns.

For this exact metric, a dedicated reporting app is the most reliable solution. Full disclosure, I'm on the team that makes Timepiece - Time in Status for Jira, and we have specific reports to extract this data.

To find tickets that are bouncing around, you can use our Transition Count report. If your different queues are represented by workflow statuses, this report will instantly show you a clear table of exactly how many times a ticket jumped from one specific status to another.

If your queues are based on assignment changes rather than statuses, you can use our Any Field Count report to see exactly how many times the "Assignee" or "User Group" field changed for each ticket.

This gives you the precise metric you need to identify "bouncing" tickets without any manual spreadsheet manipulation or empty data exports. You can check Timepiece on the Atlassian Marketplace. 

Best,
Birkan

[Lukas Maczejka - JXL]

Hi @Placid Cardoz,

The reason the history data comes up empty in Jira's list view is that Jira doesn't expose changelog data as columns in list or board views. The reassignment history exists on each individual issue (under Activity > History), but there's no native way to pull it into a tabular view or report across issues.

Here are a few approaches depending on what you have available:

Automation counter (simplest) Building on what @Christopher Yen suggested: create a number field (e.g., "Queue Change Count") and an automation rule triggered by field value change on whichever field drives your queue assignment (team, component, or a custom field). The action increments that number field by 1 each time it fires. This gives you a sortable, filterable metric on every ticket going forward.

JQL for spotting bouncers If you know which field determines queue placement, you can use JQL to find tickets where that field changed recently: "Your Queue Field" CHANGED AFTER -30d ORDER BY updated DESC. This won't give you a bounce count, but it surfaces the candidates.

Atlassian Analytics If you're on a Premium or Enterprise plan, Atlassian Analytics can query the issue changelog directly and build reports on field change frequency over time.

If you're open to using an app from the Atlassian Marketplace, JXL for Jira solves exactly the problem you described. JXL provides history-based columns that you can add to a spreadsheet view, including "Number of times in [status]," "Time in [status]," and "Time with [assignee]." You can sort and filter by these columns to quickly identify which tickets are bouncing the most, then export to Excel for further analysis.

Disclosure: I work for the team that builds JXL.

Cheers, Lukas

[Rahul_RVS]

Hi  

You can use Jira Rest Api's to pull this information and build your own custom solution.

However if you need detailed reporting to track changes for multiple issues, you may want to have a look at a mktplace app for the same.

We have built an app to extract changelog data in a simple and easy to use interface. The data can be exported to a CSV file as well.

It provides complete details of who changed the data, what was changed and when. 

Issue History Reports

Do give it a try.

Disclaimer : I am part of the app dev team

[Christopher Yen]

Hi @Placid Cardoz 

Our team queues align with a custom field so we track this using an automation rule that adds 1 to the counter each time the value changes for our team field

The custom field ID is the field itself so it just adds +1 to the value each run

[Arkadiusz Wroblewski]

Hello @Placid Cardoz 

I think the key question is what actually changes on the issue when it “moves” queues. In JSM, queues are filter/JQL-based views, not usually a native tracked field by themselves.

So I would first check the queue definitions: are they based on Assignee, Status, Request Type, Priority, or a custom field? If the queue is only a filtered view, then the better reporting target is usually the underlying field history that caused the ticket to appear in another queue, rather than “queue changes” directly.

Since you are on Enterprise, Atlassian Analytics may also be a better fit than Sheets for this, especially if you want to analyze repeated routing changes over time.