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

[Gina Sabella]

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?

[Dirk Ronsmans · Accepted solution]

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 :)

[Iago Docando]

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 :)

[Gina Sabella]

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.

Thoughts?

[Dirk Ronsmans]

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

[Iago Docando]

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.