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.

[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.