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?
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?
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 :)
This is helpful. That's one way.
I'm also thinking of creating actual "team groups" with members-
Make sense? Between status change time stamps and "Team Group" and user assignment time stamps- I should be able to calculate my metrics.
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
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.
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 ...
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