nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Assigning a group as default assignee for a component or as the component lead

Gordon Clark_s3kt2b

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?

Thanks.

Accepted answers

All comments

Rachel Wright

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: dev-team@company.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,

Rachel Wright

Josh Steckler

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.

Brittany Wispell

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.

Happy Monday!

Rachel Wright

Great point @Josh Steckler about the wasted licenses!

And while we're at it: don't create a generic/role/service account user with the username of "unassigned." I just found 5 of those and killed them. Gross!

Gordon Clark_s3kt2b

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.

Josh Steckler

@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.

Matt Doar_tzgiej

Oh yes, that really messes up Jira reporting!

Matt Doar_tzgiej

Sometimes, "assigned to everyone" translates as "assigned to no one."

Very true!

Jonny Adams

@Gordon Clark you might be interested in using Automation for Jira which will allow you to assign users in a group using a "round robin" method. That would allow you to auto assign to the group and evenly spread the work around.

Gordon Clark_s3kt2b

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

Sean_ad2thr

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.

White Software

Hi @Gordon Clark

We just released a new plugin "Groupee Group Assignee" to make groups assignable. Please give it a try and if you need more feature, let us know.

Regards,

Omer

Gordon Clark_s3kt2b

Hey @White Software . I missed this post. Thanks for thinking of me. I'll check it out and let you know my thoughts.

White Software

Thanks Gordon! We want to improve our application, any comments will help us!

Jeff Guthrie_2hjuki

Our use case is when one DevOps or support team creates a child ticket or sub-task for another support team. they may not know which specific individual within that team to assign it to, so we would like them to be able to assign it to the team.

Currently we created a sudo-user for the team and add that to the filter for their dashboard. However, once the issue is assigned to a specific individual we lose that filter.

I know in ServiceNow we had the Assignee and Assigned Workgroup. This way we could assign it to the workgroup, then within the group they could assign it to an individual. This made reporting by workgroup and associating SLAs by work group much easier.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-service-desk

group

component