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!

Hey Alan,
Can you please share your experience in setting it up in more details (few screens and description of the logic)? Probably that will help a lot of people from this thread. Thanks!

Other ticketing systems as for example Service NOW are able to do that also because complex services are organized by groups of people ....and sorry atlassian but services at certain level are not using Jira.
I sincerely suggest to Atlassian to change Product Owners since this ticket was opened on Oct 2013 -> we are on 2022.
This is not finger-pointing but the reality.

Best regards

We did this in our instance using an insight, customer field process and it works pretty well.  It would be better if out of the box it would do this.  We have to create automations and other processes to make this work when it should just be available by default.

I voted for this issue, i would like to know that if you are planning to implement this or not?

I voted for this issue. Do we know if this is on the radar for development and a release date? What is the work around? I have worked in ServiceNow, Remedy and Service Center. Not sure how you can release a Service Management product without it or a better way of assigning tickets.

@Jehan Gonsalkorale I have also Voted for this issue. This is a pretty big requirement if you want to complete with the bigger ITSM tools. All ITSM tools work on the basis an Incident or Request ticket are assigned to a "Assignment Group", "Team" or "Bucket" if you will. And then a queue manager will monitor that teams group and assign to individuals. Also when assigning a ticket to a team, that Assignee field should only present the members of that team in which the ticket can be assigned to. Currently using custom fields means you can assign to a team but still choose any assignee in the system.  Please make this a priority!

Hello to all who are commenting on this ticket!

Could you make sure that all of you have also voted for the ticket? There is the place to vote for that in up right corner. I'm not sure is Atlassian counting the comments or reading them, but I think they are looking in to the vote count.

We need this very much as well. Let's try to get it pushed up in the priority list all together!

This feature is so common to other ticketing systems that I took for granted that JSM had it when I encouraged our org to start moving to it. Now we want to branch out to having a more collaborative usage of the product between teams and I have to tell everyone that we can't actually work the way we have been working all this time with this new product.

Yes, you can move cases between projects if all the fields are the same but that is cumbersome and involves giving rights to both spaces in order for users to do this. Please give us a way to assign a ticket to a "group" or a team so that we can have on-calls and such who might be assigned to check that team's queue. 

Endorsed.  I understand the logic behind only having an assignee, but with 100+ IT staff in multiple teams, we can't expect our Service Desk to know who can actually action a particular job.  When we've got hundreds of applications and services.

A Support Team / Support Group function (Ideally, those teams would also be mapped to an AD Group too.) is a real must-have feature.  I'm amazed it doesn't have it.

Great suggestions @Jeyhun 

Consideration:
There is "Team" custom field already in the system. It looks like it may work for the Support Groups, but unfortunately it`s part of Jira Software Premium subscription. 
As the possible resolution:
a) Allow assignment of the tickets to the Teams in the JSM.
b) Allow creation of custom fields with Team picker option (better).
c) Unlock Team custom field in Jira Service Management without buying Jira Software Premium subscription. 

I would say this is a must have options. Any other ticket system has this.

We are currently working to make transition to Jira ITSM and for us this is a bit of a headache at this moment. Since we have a few different teams that handel different types of tickets and first line support assign tikets to those groups. 

+1

very useful for our design as well 

Hi guys,
It`s pretty generic option which is available in many other products. It`s almost must have for us, as we are using workaround with Global groups (not best practice at all). 
I apreciate the roots of JSM and believe that it`s not crucial for other templates, but is Service Mnaagement this feature is really usefull. 

Hi. We want to know the status of this request please.

+1

Same here

it is definitely important to us as we are running 24/7 support operations

interested very important to us

Very very important for us as well.

+1

Deffo needed - we are currently using dummy users consuming a licence 

+1 Very important

+1

+1

Hi all,

Thanks for your feedback. We are reviewing this now and will get back to you soon once we have next steps.

We appreciate that this is important and will do our best to keep you informed.

Best regards,

Jehan Gonsalkorale

Product manager, Jira Service Management

+1

we really need this

+1

+1

+1 

Availability of assigned groups, I believe is a basic requirement of a ITSM tool. In order to workaround this deficiency, we have created multiple dummy accounts and multiple statuses with the assignment group names to make it clear. We are having great difficulty when not having a centralised/Leveraged resolver groups so ended up creating dedicated projects for different customers. Also, reporting is tedious without this feature. Please consider this feature for your next release.

we came from Hubstaff Tasks where we can assign task ( for example called meeting or management ) for more than one user, it's very important for us to do that, can we you please add this to your future releases?

thnaks for your reply, let me test / review those elements. regards

We often would require more than one person to be assigned to tickets in the case that person A is away, person B would be able to pick up the ticket to work on it. It is odd where it is only restricted to a single assignee.

This feature needs to implemented. We have now round about 100 dummy user accounts which has assigned the team email address.

Yeah, this should have already been included as a basic feature of Service Desk - it's not some crazy idea, this is implemented in other service desk systems that have been around for decades. JIRA already sees the AD groups - they're right there - it's so close, yet so far away.

While the "Teams for JIRA Service Desk" plugin is interesting, it's not quite what we're asking and seems to require the additional management of teams that are in JIRA and not AD.

Marc,

Looks like a good plugin. It is not available for the cloud unfortunately. Also, this basic feature should be part of Service Desk for free. I really think it should be a basic feature that's included with Service Desk. This feature is common in other Service Desk type of apps.

Maybe this plugin will help some people accomplish the ability to assign to a group of customers:
https://marketplace.atlassian.com/plugins/eu.prepend.jira.servicedesk-teams

Agreed with Joe above. We really could use the feature where we can automatic assign a new issue to a group. It gets messy when you have many people on the support team and it is hard to auto assign to one person. Also, it is not a good idea to leave the ticket unassigned either.

Please implement the ability to assign an issue to the group.

Thanks.

Just to provide some feedback to Atlassian about how this would work because I can't fathom why this hasn't been implemented yet...I run the User Support team for a company of 8000 people, with roughly 100 support personnel across multiple countries. Those 100 support personnel are broken up into multiple teams, such as Help Desk, Desktop Support, Remote Desktop Support, MobileOps, PrintOps, Infrastructure, and more. Our JIRA with service desk is connected to AD and pulls users and groups. When a ticket is created, I want the system to assign it to a group, like Help Desk. The manager of that group can assign the ticket, or a team member of the group can grab the ticket and assign it to themselves. If someone needs to escalate a ticket, they can just assign it to the next team and not have to single out an individual. The current work around for this is to create a user account in JIRA that is tied to that group in AD - it just gets really messy and requires more manual work that we shouldn't have to do. To answer Shihab's 2nd question, you would just make it so the "Assignee" can be a group or a user. No need to get fancy and have a ticket assigned to a group and a user at the same time. Let's just tackle this low hanging fruit request first. Thanks

Comment deleted, in the wrong place

We have an existing ticketing system that can assign issues to groups. We use them flexibly, where work can be pulled by an individual and reassigned to themselves, or simply stays assigned to the group, where the work can be shared.

This works well in small self-managed teams, where there isn't a manager keeping an eye on ticket assignments.

Thanks for suggesting this feature!

How do you guys see this working?

• What does assignment to a group mean? Will members of the group pull work on tickets that are assigned to the group?
• If an issue is assigned to a group, can it also be assigned to a user at the same time?