Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

One Project for Incident, Problem, Change and Request Management (Assignment Groups)

I am finding it difficult to measure and report on the lifecycle of an Incident and Request with multiple Projects. Thinking about rolling up to a single Project, but since "queues" are really filters, I'm not seeing a way to measure items like-

Time to Accept

Time to Escalate 

Time ticket is assigned to each group

Actual Resolving Group

Group assignment at the time a SLA is breached



Some Folks may be assigned to multiple Groups

Can "Assignment Groups" be created and display on tickets?

Any recommendations?



2 answers

1 accepted

1 vote
Answer accepted
Dirk Ronsmans Community Leader Jan 22, 2021

Hi @Gina Sabella ,

It does make more sense to keep the processes from the same Service Desk in one project (or could even be from multiple Service Desk teams) so rolling up is definitely a possibility.

How would you actually measure these things right now?

  • Time to Accept
  • Time to Escalate 
  • Time ticket is assigned to each group

they sound like they would be SLA's? If so you can create all the SLA's in a single project and just define the correct filter on the goal (including the issue type) so that should not be a problem.

As far as groups go, that's not something that really exists in JSD/JSM. We tend to fix this by adding a custom field "group assignee"/"team"/"resolving group".. something like that.

When a ticket is first assigned the agent would need to select a group (or when it is re-assigned to another group too).

This allows the group members to handle their own internal assignment through the assginee field.

The drawback here is that the assignee field is not filtered based on the group so they would see everyone. But if you have the group itself handle the user assignment that should not be a problem as they know who is a member of their group.

The resolving group could be just the last group that it is assigned on when the issue is resolved OR if you really need is separate you could add a custom field "Resolving Group" and set that on the transition screen (as mandatory) when you Resolve a ticket.


Hope this helps you a bit, if you have other questions feel free to elaborate a bit on your use cases. The more information we have, the better we can reply :)

I guess I failed to recognice she was using JSD  and I tried to explain a general approach to do those calculations in jira server. The "queues" part was obvious yet I missed it sooo allow me to upvote your answer :)

Like Dirk Ronsmans likes this

This is helpful. That's one way.

I'm also thinking of creating actual "team groups" with members-

  • ServiceDesk Assigns "Team Group" to an incident (this is my "escalate")
  • Set filters up for each "Team Group" so they only see their issues (Queues)
  • "Team Group"s then assign their tickets to individual users

Make sense? Between status change time stamps and "Team Group" and user assignment time stamps- I should be able to calculate my metrics.



Dirk Ronsmans Community Leader Jan 22, 2021

Makes total sense to me.

Would be exactly how I would set this up. JIRA did introduce a "team" concept but it has no real value yet. I'm hoping they will be moving towards a 

group assignment and then user assignment model soon cause that just makes sense if you have multiple teams/levels within your service desk structure

0 votes
Iago Docando Community Leader Jan 22, 2021

First of all let's talk about the assignee part. You can have a custom field to select a group, sure, but as far as Jira is concerned the assignee of any particular issue can only be one single user.

So, in order to show the ACTUAL resolving group you could simply have the actual assignee (the one that resolves the task) fill/update that field in the final resolution screen or you could go fancy and try something like a custom script field that searches for the name of the assignee within the user groups and then return the group name as the value for the field. You'd have to code that yourself.

Also, I haven't really understood the problems you believe you have. I think you could use just one project with different issuetypes for incidents, problems, changes or requests and a custom workflow schema in the project so each issuetype goes through its own workflow but you could also if so you choose have it set up across multiple projects, one for each issuetype. Nothing weird there, it's more of a personal choice you shoud make based on your particular use case (who should see / manage each issuetype? if visibility is a problem it might be easier to set up different projects rather than having to configure an issue security schema but in the end it is just a personal choice)

To track the times, one option would be have an automation so everytime the issue transitions to any status you are interested in the value of a date field is automatically filled with the transition time, let's say the moment a ticket is "accepted". A calculated field can do the substraction of that date of acceptance minus the date of creation... and there you have your "time to accept".

In general, any parameter you want to track that begins to have a rather long name implies a certain logic to calculate and a fair amount of complexity so you should probably use something like scriptrunner or similar in order to being able to define the logic behind the calculation.

Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Software

Presenting the "Best of 2020" Jira Software roundup!

Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...

7,121 views 8 28
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you