Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

You can already assign to a group/(s).

1. Create a custom group field named 'Assigned Group'.
2. Project settings > Permissions > Assignable User > Group custom field value > 'Assigned Group'
   • You can remove the other items that you don't want to be assignable.
3. Create the Atlassian Groups and members that you want to assign to.
4. Give your groups that you're using for assignment roles in your project.

This allows you to assign to a group or multiple groups and the assignee MUST be a member of the chosen group/(s).

The stupid part is all the automation that you have to do in order to make it work like you'd expect assignment groups to work. The group field doesn't have contexts or allow you to limit the groups that you can choose from so you end up having to use automation rules to map the correct 'Assigned Group' using either a custom select list where you can dictate the values or Atlassian's Team field. Otherwise you end up being able to assign to the administrators group or any available group... Also the automation rule needs to detect if the Team / custom select list changes that the current assignee is actually a member of the new groups or the previous assignee will just stay there.

There is a full tutorial with example scripts here where you can even sync members of Atlassian Teams with group fields and get the functionality of both. Atlassian do have an EAP to link Atlassian Teams to Atlassian Groups but it's only for groups synced with an IDP

The ability to assign a ticket to a user or group is a common action for most ticketing systems.

This feature is already requested since 2014, 10 years have passed.

This is an eternity of time, this should already have been actioned, what's holding this update?

While we wait for this one, ScriptRunner has a workaround that might help. You can combine the functionality of Jira Groups with the Team field while keeping members in sync. We’ve written up a tutorial with example scripts here.

Definitely something that would be useful in our organization. 

I have users that urgently want this feature and are reluctant to use the default Assignee field on any ticket as a result of this limitation. 

Hi shamid@atlassian.com (and assignee a1217920d496) ,
please check on how works in Service Now.
Here the documentation
What does assignment to a group mean? -> if you manage 24/7 services o events (e.g Sports events where there are tons of groups doing different tasks) you will discover how much is important this feature.
Will members of the group pull work on tickets that are assigned to the group? -> yes obviously
If an issue is assigned to a group, can it also be assigned to a user at the same time? -> user of the group.

Best regards,
Roberto

Hello f8c2914d44e4 - what did you do to sync the Opsgenie Teams with the Jira Teams?
We have migrated from Opsgenie to JSM, yet. We realized, that the teams are not merged. Now we have the OpsgenieTeams in addition to the Jira Teams and are thinking about - how to consolidate this.

We use OpsGenie and the Affected Services field. We associate an OpsGenie Team to every Service and use OpsGenie to notify the Team when work has been assigned to the Service.  We have an automation that synchs the OpsGenie team with the Jira Team until these get merged in the future natively.

-----------------

we hired a company ([Automation Engineering | 5.15 Technologies (515tech.com) |https://www.515tech.com/]to use the OpsGenie API to synch the OpsGenie Service Team members and description with the Jira Team members and description... API Overview (opsgenie.com) 

We solved this Problem by using another custom field called "Bearbeitergruppe", this custom field corresponds to groups, which we configured in assets.

This way ist a workaround, we implemented 1 year ago.

At tve Moment we evaluate, changing to the Teams (which we used in Jira Software, before). These Teams are now merged with opsgenie Teams and in our opinion the petfect way for "assigning" issues to Teams in JSM.

A Agent can assign any issue to himself, the Team stays in the issue.

The Workflow around this can be automized, assigning a Team, according to chiden Hardware, Software,... Status Changes when changing Teams or filling in an assignee,...

Regards

Ralf

+1

Hello to all, 
to push the ticket and accordingly the feature implementation once again: 

USE-CASE: We need also a feature to form - instead of an individual agent for operating a JIRA request - a whole team to be allocated a certain request. I mean not to assign a request to different agents, but rather certain roles and / or groups in an existing process. These teams should be seperated from each-other concerning the ticket operation, but not the whole request process.

BACKGROUND: Our customer wants to provide their requestors with a transparent process where a request takes differents steps in a approval process according to the specifical nature of the request.

Unfortunately, the suggested workaround - thanks - resolve our issue.
Hopefully, this brings some progress in the request initiated over almost ten years.

Thank you in advance, best regards
Marc
P.S. I will also publish this message below this ticket: JSDCLOUD-1268 Support adding a Jira group to the "Request participants" field - Create and track feature requests for Atlassian products.

I will say while this is something that Atlassian should just be offering I did come up with a custom solution for this issue. Create a custom field called group/team and then add an automation to notify specific people when a ticket is assigned to that group. For my purposes the group is a notification vector but an individual will take the ticket after the group gets it and I really only need to contact the group to tell them about a new ticket. 

Hope this helps while we wait for this feature from Atlassian. 

This ticket has been open for many years...

How is it possible that a simple feature like this is not been added?

Seems like Jira wants us to pay a user license for each group for us to be able to assign a ticket to a group.

Please, the ability to assign a ticket to a group is a MUST.

This needs to happen.   I don't want to create automation assigning tickets to a user and when the user moves up or out have to go back and figure out all the automation changes.  We need to be able to assign a ticket to a group and as people come and go we update the group. 

The 2 options we had employed are to use a user record that's solely for notifications which takes a up a license and then a queue that looks at anything assigned to that user account OR using a custom field for assignment groups, which is super frustrating since this is such a base level function in all other ITSM systems. Almost makes it difficult to converge users to use JSM in the absence of such functionality. 

I hate to pile on when it has been said so many times, but.....

We could really use a feature like this.  It is surprising and somewhat disappointing this hasn't been added by now.

Very interested in being able to set-up agent groups in Jira Service Managment in order to be able to notify a specific team within the company that there is ticket for them to work on in Jira.

This is very much needed in our organization as well. Jira team please consider?

Best regards,

Hey @Martin Ben, the Atlassian team! Are you planning a celebration for the 10th anniversary of this ticket? Maybe some kind of party, webmeeting? This is a great opportunity to show users of Atlassian products your commitment and dedication. Not all of us realize how much work is behind these long 10 years!

This feature request is coming up to it's 10th birthday  

I forgot that I added myself to view, but I am surprised this still is not a feature; we just finished our ServiceNow Implementation and this was one of the biggest reasons why this tool does not work - especially when you have shared resources supporting multiple different areas. It's a shame this still is not there. 

Agreed, this feature is in ServiceNow which I used with an IT department of 2,000 IT workers.  It worked beautifully.  

As everyone has mentioned Atlassian really needs to prioritize this as it is critical for any larger IT team. We want to ensure that different sub-teams have their assigned tickets that they can get notified on and can view in the dashboard. I will look at some of the work arounds discussed but this needs to be prioritized. 

It's been a few months since the last request for an update.  Anything new with this?  

Atlassian Team, do you have an update on when this feature will be available? We are currently paying for additional licenses with JSM to accomplish this. Please provide an update. Thank you.

We are migrating to JSM from another Help desk tool and can't believe this very basic feature is missing.... what gives?

Any updates?

For service desks, this a very important feature. You work as a team and want to assign a ticket to a group so you can collaborate. It would already help if we can make assignee-groups and assign them to a ticket, instead of assign multiple assignees individually. 

Gathering interest... what a joke. Our company is switching to a different system because of this and sooooooo many the juvenile problems with Jira.

Ah, yes! Great point, Chris Riffey! As you're setting up a queue, you could specify an e-mail to send a notification to that an issue has hit the queue. I think that would likely be much easier for Atlassian to develop instead of trying to get the assignee field to allow a "group."

We're actually utilizing the Status to notify the two teams who manage tickets in our helpdesk.  It works for now, but if we ever grow it could prove to be incredibly difficult to manage.  

When a ticket is raised, it goes to a generic queue and our "Helpdesk" team is notified via an Automation.  We have another automation that is set up so when an issue transitions to "Escalated to App Support" an e-mail is sent out to the app support team.  Likewise, we have another automation when the issue transitions to "Escalated to Helpdesk Support" and it notifies the helpdesk team.

I don't think our solution is very scalable, but I can see how utilizing a custom "group" field could be easier to maintain.  Thanks for the idea!

Now that I have worked with JSM a lot more I can see why this is not something that they have already implemented as it would require a core change to the way the system works. The system/database is built on the idea of a single assignee (probably because it was built out of the Jira Software system designed for project/task management) and it would be fundamentally different to have an issue associated with multiple users. 

The other problem is that the issues aren't really compartmentalized in the system except within the project. The queues are just ways of visualizing groups of tickets a certain way but they don't live in different containers like they do in the other ITIL-style service desk options most of you are probably thinking of. 

We got around these limitations by creating a custom "group" field that was added to every issue type and visible in the ticket details. Then either the agents change it to assign tickets or automation changes it based on created request type or email "from" address. We then set up Jira groups (via Atlassian Access and our AD) and set up automation so that when the field gets changed to a specific group, it notifies the appropriate group of people. We then set up queues that were filtered based on the group field and you have a good approximation of what I think most of you are looking for. We have been using it for a few months now and it seems to work pretty well.

However, it was a lot of work to set this up and have it working well and you really shouldn't have to do this. I think Atlassian could meet this need half-way by simply adding a system to notify a specified group or user when an issue hits a queue. Then with what is already there we could create new request types and filter the queues based on those. 

Is there a timeline or any possibility this will be implemented? Considering it has been proposed since 2013, we are most likely going have to move to a different ITSM tool, as this is a critical feature and prohibiting us from adopting it further and maturing. 

Our customers who adopt Jira Service Management needs this feature and demand it. When they learn that it is not available...they do not understand why and required workarounds...

Our company is also looking for this feature and it would be very helpful.

This really is a basic feature that should be implemented. I know there is an argument about who is accountable, but the lack of this feature requires additional operational/creative overhead to accomplish what should be out of the box and standard. It makes reporting on which level resolved it, which team or group has assignments, cost per ticket per level, and so much more, it also makes automation much more difficult than it should be to assign to a team or group. 

The lack of this feature would be great for a mature organization that can accomplish this, but for the majority of organizations (probably 90%+) that actually want to use this for a enterprise or IT Service Management tool, this creates unnecessary frustration and a lot of conversations to have key stakeholders understand that this is not a standard feature or easily accomplished and the tool does not have this standard capability. 

I do not know how to vote more than once, but if I had one vote a day for a year - I would use all of my votes for this feature. 

This product is selling big on its automation capabilities but if you want to build an automated assignment mechanism, then you are out of luck. You need to deploy a workaround like putting users in groups just to be sure the automation will not assign an issue to someone who is out of the office or working on a later shift. 

I have 10 different teams, each maintaining different parts of the application, so automated ticket assignment is also a chore as instead of "assign to a team" (and then worry who is in the team atm) either have to micromanage the user list or micromanage groups. 

How is this still in GATHERING INTEREST and not yet reviewed by the product team ?

We have to use so many custom workarounds to achieve some flavor of this need ... 

To be honest this such a deal breaker when you have multiple teams. If I had know this before we made commitment to switch to Jira ITSM  I would have gone to Service now. 

After almost a year of using it now with many workarounds and frustration moments I am starting to wonder if switching to something else like Servicenow might be better for our company.

please implement it..our customers doesn't understand this lack with respect to the other products (i.e. ServiceNow)

please, implement this... it's a very big limit that require a of customization to overcame.. 

Can this be implemented? It has come up at least 3 times this week. Since we have groups that employees are in with 13 branches alot of times other employees do not know who to assign tickets to in another branch. It would be helpful to allow a user to assign a ticket to a group to then let the system round robin to the right person in that group with that skill set in that branch.

This feature has been requested almost a decade ago, how is this not implemented yet?

Workaround

cons: You will need to handle synchronisation of agents in Insight object User.

To display tickets for user's groups in their dashboard, you can do following:

Create two insight object types: Group, User.

• Group has attribute "Members" of type Object referencing User.
• User has attribute "Jira user" of type User. 

Create custom field "Resolvers", with IQL filter "objectType= Resolvers"

Prepare a dashboard filter for "tickets without assignee assigned to my group": "Resolvers" in iqlFunction("objectType = Group AND Members.\"Jira user\" = currentUser()") AND assignee = EMPTY AND resolution = Unresolved

To notify the Resolvers group about new tickets

add attribute email to User object.

create automation:

1. trigger: when value changes for "Resolvers"
2. if: Resolvers not empty
3. action: edit issue: remove assignee
4. action: create variable:
   1. name=emails,
   2. filter=#issue.Resolvers.MembersEmail^last,/{
      Unknown macro: {/}

      }

5. action: send mail:
   1. to={
      Unknown macro: {emails}

      }

   2. subject=New issue issue.key - {
      Unknown macro: {issue.summary}

      }

Hi All,

I got a alternate of this option and not 100% best solution but workable.Also,Most of the people already used these below mentioned steps but I am putting my comments what I get to get rid of this issue with Jira Service Management.

1.) Create a Group Email in active directory and add those people which is related to that particular team.

2.) Create a user similar like group Email and provide the license to that user.

3.)Now, you can assign the issue to that group and all the people associated with this group can get the Email notifications once the incident has been assigned to them.

4.) Team can also login from the particular user which is created earlier and start working on incidents.

Benefits:

You can use one license for group account and share with team so costing is less.

Drawbacks:

1.) Due to Dual authentication, one spoke has to provide there contact detail so that get the OTP for login from that common user account. However, Dual Authentication needs to stop.

2.) You can't track which user is working on any particular request as users are login from common account.

3.) you can provide the license to individual once as well but it may increase the costing.

This is a very important basic function, which will also solve the problem that a person in the group is assigned an issue when on leave to a certain extent.

Created 25/Oct/2013 - 

Current Year 2022

For a functionality which should have been there in a first place. sad to see its still gathering interest

This is one of the painpoints missing from JSM. I vote for this.

This seems to be another thing that we have lost due to our move to cloud - when will this basic functionality be provided?

I too vote for this feature. Its a shame that such out of the box feature isn't yet made available

Hi,

I want to vote for this feature and other product already having this functionality but why Jira service Desk.

It's quite difficult for us to add watcher one by one and assignee the ticket to particular person. This is a tedious task for us and Atlassian need to quickly add this functionality in Service desk and service management.

Thank you.

Voting for this feature to add asap

I also Vote this issue up as a requirement for Service desk.

The fact that this is not possible, is baffling to say the least. Lots of other smaller and larger Service desk have this feature for years.

As said Roberto, this is a great shame for Atlassian! How it's even possible to "gathering interest" of such a obvious functionality from 2013? It will be a decade soon! I don't understand this at all!