At my old company I was able to assign a group as a component lead, and then use that group as the default assignee. Same thing with a project. By doing this, I was able to have a group of people automatically assigned (and thus notified) when a new Jira issue was created. I believe we had a custom instance of Jira, so that may be part of it as I'm currently using a standard cloud version.
That doesn't seem to be available anymore. Can anyone provide any insight on how to accomplish this?
Hi @Gordon Clark,
I don't see a way to select a group for a Component Lead in either Jira Server or Jira Cloud. Is is possible that you instead had a generic user (ex: "Dev Team") with a distro email address (ex: email@example.com) which sent email to multiple users?
I usually don't recommend assigning issues to one of these types of generic users. Sometimes, "assigned to everyone" translates as "assigned to no one." You'll want to train your users how to find items without depending on email or something being assigned to them. :)
Would it be possible for you to separate the concepts of "assignee" and "notification"? For example. you could use your project's Notification Scheme to notify a list of people (ex: a group) on create or update, but still keep the assignee set to just one person (or even to null, i.e. "unassigned").
Hope this helps,
The only way I know how to do this is to create "fake" jira users that are in the local Jira directory, and whose email address is set to the group address.
Then you need to provide those accounts a license, and the appropriate permissions on the project (browse issues, assignable user).
Downside is that, yes, this solution will take up some of your licenses.
Hey @Gordon Clark
I am curious to the use case and reasoning behind making a group the assignee of an issue?
It is not typically best practice to do this, it's not an out of the box feature of Jira either, so it is probably a customization. If it is notifications that are needed then you can leave the issue unassigned but notify the group of the creation of a ticket. You can do this by changing the notification scheme of the project. If you need instructions on how to do this, I'd be happy to post some steps as images on how to achieve it.
If not I'd be happy to have a more in depth conversation of your process to help you get what you need. :)
@Brittany Wispell I actually find that this has use when multiple teams use the same Jira project. One use case is Jira service desk. While I don't use the Assignee field, I have a user picker with my "fake" users as options, and the request types automatically set the right team on creation. Then I use that field in the notification scheme.
Why not a group picker? Because I can't limit the scope of a group picker, and I only want certain choices visible.
Wow, thanks for the rapid responses everyone. So, I think with this use case, I could get away with doing the assign to one person and notifying the rest.
However, think of the initial ask as this: A work request comes in as an issue, depending on the customer, one of X people can pick up the work depending on their availability. This group of people are all very professional and well training, so issues floating around unassigned aren't really a big concern, but we can address any stragglers easily with queries.
I'll look into notification schemes some more, but what I really need is to have this type of behavior at the component level, not the project level.
Thanks again to everyone for the quick responses.
p.s. - I think those of you who suggested that we perhaps had a "group" assigned to an external d-list was the way it was working. I also think the old company had an unlimited site license, so it wasn't an issue on the licensing.
Hey @Jonny Adams. Thanks for the reply and the recommendation. I took a quick look and will investigate in more detail later, but what I really need is a pooled list workflow concept. It's not so much about evenly spreading the Jira issue work around. It's more about those in the pool understanding their own workload (reflected inside multiple Jira projects AND outside of Jira entirely), and taking on Jira issues based on that workload. Bottom line is some human intervention is required because Jira doesn't have enough information to make that decision. I want to go the component route because the pool changes based on the project/customer (not Jira project, but our company's project/customer).
I would like to see this option as well. Perhaps it makes sense from a Jira project perspective, or for a small team of service agents, but in my experience it is bad practice to automatically assign tickets to an individual or route to individuals instead of groups. What if that individual is out sick, on vacation, in a meeting, or just really busy? You want the ticket to go to the next available agent for the fastest resolution possible.
Of course there are some cases when the "who" it gets assigned to is more important than when it gets completed... so I'm not saying there are no exceptions. That said we always have at least two individuals assigned as subject matter experts for a component. They usually work in the same workgroup, but not always.
As this feature is currently implemented, we will just leave the default assignee blank. Our current solution is an "Assigned to Group" field with corresponding queues and dashboards. For a few components we have automatons that assign matching issues to a specific group. We could also just create custom queues and dashboards for specific components, but our staff also like to have the ability to assign any ticket to a specific group.
If anyone has suggestions for a better way to handle this I'm all ears, but our environment has about 75 agents in eight distinct workgroups (then there are small groups of subject matter experts... usually two or three). The tickets are manually assigned to groups based on a combination of component, escalation, priority, and whether or not it requires a physical trip to the desktop. Most tickets start with the front line service desk, but if someone submits a ticket there or via the Web portal that triggers an automation (or uses a specific request type) it may light up a specific group's queue depending on what components and/or labels are set.
Hello there Cloud Community members! Today, we’re thrilled to announce Jira Service Management, the next generation of Jira Service Desk. Jira Service Management touts advancements in IT service ...
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