You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We are using Jira Service Desk Management
Since we didn't have enough licenses (15 licences for about 30 users in about 10 departments),
till now there was one agent per department, so all members of this department where signing in
with the same account (15 agents overall)
We recently bought more licences (50), so we now have the opportunity to have 50 agents,
which means that each member of each department can log in with a different account.
However, when an issue is created, our help desk team would like to assign it to a group of people that belong to the same department,
since they don't know which member of the department will undertake the issue.
For that reason we want to organize our agents in groups or something like that,
so that the issue is assigned to a specific group and then all its memners
are notified of the new issue that has been assinged to their department
Any ideas of how to implement the above procedure?
Thank you in advance,
Jira (and Jira Service Desk) are deliberately designed to not have "group assignee". In the real word, group assignee does not work, it fails people all the time. Not because the idea of "assigned to a set of people who will get it done" is intrinsically wrong, that is fine, but humans simply don't work that way.
Jira and JSD do not allow for group assignee, but they certainly are built for "we don't know who this should be given to", especially JSD.
The basic principle for incoming requests is that there should be data on an issue that enables you to define one or many queues, ordered into most urgent first. In the most simple case, you then get your agents to simply work from the top of the queue - pick the highest item off the list, assign it to yourself, and deal with it. Where there are multiple teams, your ideal situation is a single queue per team.
This way, you don't need to know the individual or even group to assign it to, and it gets given to the person most likely to get it fixed.
Hi @Aggeliki K
this way appropriate people will get email notifications once a ticket pops up in the filter. Make sure the subscription runs every hour (or more frequently if you need that) and make sure people assign tickets to themselves as soon as they see it (this way the filter does not send multiple email notifications for the same ticket).
We do similar, but we called it "Support Queue"
If your groups/queues are actually defined as groups in Jira, then you can add the group custom field to the create notification, and the members of the group will get an email as soon as the issue is created vs having to wait for the filter.
@Andrew Laden, I configured your solution in our JSM but for some reason it's not working, i.e., it's not sending the Issue Created notification to the group defined in the custom group field. I think the issue might be timing... I'm using a "When Issue Created" automation rule to assign the group to the custom field. Is that the right approach? Any help would be appreciated. I feel I'm *this close* to getting this working...
For context, we have 3 separate agent groups all sharing one project. I have a "When Issue Created" automation rule that looks at a few fields on the issue to determine which group(s) need to handle the ticket. This is set in the custom group field, which is then used for notifications, automations, and dashboard filtering.
I would agree its a timing problem. The notification engine and the automation engine both work off the same event, the Issue Created event. (which should be the last step in the create transition post function.) So the notification goes out as soon as the issue is created, while the automation engine is still processing its rules.
3 solutions off the top of my head (I am sure there are more)
1: Instead of using automation to assign the custom field, Do it in a post function that happens before the Create Issue event is fired. This will probably require an addon of some sort. You could do it with scriptrunner or powerscripts for pure flexibility, You could probably use Update on transition, Jira Suite Utilities (JSU), Jira Misc Workflow Extensions (JMWE) or even Workflow Enhancer for jira. Any of those should allow you to have a post function execute based on the value of a custom field. (again, there are probably others.)
2: Since you are using automation to set the value, just have automation send the notification to the group as well. It may not have the same look as the create event notification, but it will get the job done.
3: Create a custom event, and have the automation fire the custom event, and set your notification rules to email the group in the custom field. (JEMH has a similar problem and that is how they get around it.)
one of those should work for you.
Thank you for the prompt and thorough reply Andrew - you're amazing! My thoughts:
1. I'd prefer to avoid addons (for now at least).
2. This was how I was going to implement it initially. I prefer the "fancy" template that JSM uses for Issue Created notifications, but as you noted, I can include all of the relevant information so it'll get the job done. (It may be even better since it can also include some custom fields.)
3. Yeah, I found a similar post (there are several) after I submitted my question to you. For those who are interested, here's the link to one of them: https://community.atlassian.com/t5/Jira-Service-Management/Notifications-for-Group-Custom-Field/qaq-p/788931
I think I'll go with option 2, as it's the simplest for me to implement. Thanks again @Andrew Laden!