Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Field value duration for BI purpose

slucchesini
Contributor
July 17, 2026

Hello,

This is basically the classic "Time in status" question, except that I want to extend it to any other field.

Here's my context: we've created an Incident workflow that's meant to be very fluid. There's no differentiation between teams, and escalating to a new team is simply a matter of changing the value of the Team field, not the status or the request type. This was done for two main reasons:
- We wanted to avoid the classic "Support N1", "N2", "N3"... statuses because the organization can change and an N4 team could appear or an N3 could disappear
- We also wanted to be able to transfer the ticket to another team (e.g if the problem seems to be coming from a depandency) without creating a new ticket

The big problem is that we would like to get data on how long each team takes to manage a ticket, and we're unable to do so with this architecture. If each team had a given status or request type, we would be able to create a SLA per team, but there's no "Team field has changed" trigger in the SLA rule definitions (in any case, one SLA per team is not necessarily the best solution)... I don't want to create a field per team either and populate it through Automation.
So if I want to stick to my architecture, the only solution I see is probing every ticket's history through the APIs in a BI app, which would be very heavy.

What do you think? Is there a magical "Field value duration" add-on I could use? Should I change my architecture? Can you think of some kind of in-between solution that would keep my workflow flexible while allowing me to get my stats?

1 answer

1 vote
Alexandre Pezzini
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
July 17, 2026

Since you are on a Premium license (which does not include native Atlassian Analytics), your best path forward involves using specialized Marketplace tools or targeted automation to structure the data for your BI stack.

1. Recommended Solution for Premium: Marketplace Apps

For a "Field value duration" requirement that extends beyond just status, there are established apps that specialize in "Any Field" tracking. These are much lighter than manual API probing because they index the history for you:

  • Timepiece (Time in Status): This app includes an "Any Field Duration" report. It can specifically track how long a ticket held a certain value in your "Team" field. Crucially for BI, it provides a JSON Data Feed or CSV export, allowing you to pipe structured duration data directly into Power BI or Tableau without manual calculations.

  • Issue History for Jira (SaaSJet): This app offers a "Field Changes Duration" report. It is designed to calculate exactly how long any system or custom field value remained the same, providing an audit-ready history that can be exported for external analysis.

2. The "In-Between" Automation Approach

If you want to avoid additional apps, you can use Jira Automation to "pre-calculate" these durations so your BI tool doesn't have to.

  • The Logic: Create a hidden Long Text custom field (e.g., "Team Duration Log").

  • The Flow: Use a trigger for "Field value changed" (Team). Use an action to calculate the time elapsed since the last change and append a string to your log field: Team A: 120m; Team B: 45m;.

  • Result: Your BI tool only needs to read one field per ticket rather than the entire history.


3. Future Recommendation: Atlassian Analytics (Enterprise)

While not available on your current Premium license, it is worth noting how an upgrade to Jira Cloud Enterprise would simplify this via Atlassian Analytics:

  • Direct SQL Access to History: Atlassian Analytics provides a Data Lake that includes a table called issue_field_history. Instead of using APIs or apps, you could write a single SQL query to calculate the time between "Team" field changes across your entire site.

  • Cross-Product Insights: You could join this "Team duration" data with other sources (like Opsgenie or Confluence) to see how team response times impact overall service health.

  • No-Code Visualization: It includes pre-built ITSM templates that can be easily modified to track "Flow Metrics" for any custom field, not just status.

Verified Documentation

I hope this helps you maintain your flexible architecture while getting the precise BI data you need!

Suggest an answer

Log in or Sign up to answer