how assign the issue to groups

[Satish M]

Can you please let me know ,how we can assign an issue to group, this is the user requirement

[Dirk Ronsmans]

This is no out of the box feature.
You can achieve this by adding a custom field of type "group picker (single)" and adding that to your screens.

(or any other type of select field where you keep a list of your groups)

There will no link between the assignee and the group.

[Nic Brough -Adaptavist-]

Your "requirement" is wrong.  I know that sounds quite harsh, but it is accurate.

Group or multiple assignees simply does not work in real life, it's an unmitigated disaster everywhere people have tried it.

Jira rightly only allows for a single user to be the one person responsible for getting the issue done.

However, something for "and this group or these other people are involved" is a good thing.  Being able to identify other people to talk to about the issue if the assignee isn't around, or knowing who to reassign it to if the assignee leaves or can't be responsible for getting it done any more - very useful.

You should do that with a custom field - a multi-user picker, a group picker, or even a simple select-list with the names of the teams as options.

[Dirk Ronsmans]

@Nic Brough -Adaptavist- I'm really struggling with your "the requirement is wrong" statement.

How would you approach this use case / requirement in a (still very much used) silo  team structure?

If within JSM you have the traditional structure of 

• 1st line (SPOC)
• 2nd line (larger problems/more time investment/often on-site)
• Expert teams (Network/System/Security/...)

If a 1st line service desk employee wants to escalate an issue to a more expert group (or even an on-site team) how would you approach this then?

I'm fully in agreement that responsibility (like @Rezgar Cadro _Totem Dev_ mentions) has to a a single user at any given time.

But I still feel like Teams need to be able to manage themselves and by assigning a ticket/issue/.. first to another Team and then have that Team decide internally who will pick up the issue (either by pull or push) still seems like a valid requirement.

I personally wouldn't want my servicedesk agent to decide that I'm going to work on things that might be outside my skillset or add to my workload without them having the knowledge of other work/holidays/sick leave/... 

Having a Team/Group work on something that indeed is a bad idea.

Using a Team/Group to assign an issue to a self-managing team seems just logic to me?

In software development I get that this can be different cause you often just have a single team per project or they work by component and pull issues/stories from the backlog. But in Service Management?

Just look at OpsGenie, first thing you do is set up Teams and then use rotations within those teams to assign alerts/issues but each Team is responsible for a Service and there your monitoring solution can be considered your SPOC.

We have had discussions about this before and I don't mind being proven wrong, but I just can't see a different way of working/concept if you work within a team based/hierarchical structure

[Nic Brough -Adaptavist-]

It's quite a subtle thing, arguably down to semantics.

I always try to keep my responses to this question simple because the "right" answer is a bit of an essay question, and a lot of don't really care about it.

90% of us just need "the assignee is the person who needs to JFDI and we can add a field to represent group/team ownership"

When someone says "assign an issue to group (or multiple users)", they usually don't mean exactly that as it is written.  When they do mean it, they're wrong, not because of the concept, but because it does not work in real life.

What people mostly need when they say "assign to group" is not a group assignee, but a way to say "this group or team are (probably) the (best) team to get this done" (and the eventual assignee is probably in that group)

This changes the focus of the question.  "assign to group" is actually a solution to the problem of "how do we get this thing done by the right team", but it is the worst possible solution.

Look deeper into the question.  It's not really "who should I assign this to", clearly, as it's not up to the questioner who becomes responsible for the issue getting done. 

Going up one level to the group or team - still not something the questioner should have to know or have authority over in most cases, but often can get to the right team because your organisation probably has some rules or guidelines about which team to go to.

That's where the focus of the question changes.  Most people raising issues want to get the issue to the right team, but don't often know which team.  So the question becomes "How does a team know what people are asking of it?"

So, instead of "assign to group", what people really need is "create an issue which then gets picked up by the right team"

This leads us into asking how each team gathers their list of things to do.  Agile teams will want issues to simply land in their backlog.  Support teams would look at the queues.  Other teams might have other ways to decide who gets it.

So, "team responsibility" is a very good thing.  But "assign to the team" is not the right way to meet the responsibility.  "Get it into a team's to-do list based on how they work" is the right way to make them responsible.

[Rezgar Cadro _Totem Dev_]

As other people have mentioned, assigning to a group is indeed an anti-pattern due to single responsibility principle. 

If you actually want 10 people in the group do the same task, the proper approach is to spawn 10 sub-tasks and assign them to individual workers. That's because each user will start/finish the task at different times, produce different deliverables and you likely want to know whether and when each of the people has completed it. No need to do it manually, it can be easily automated with native Jira Automation (e.g. when task of type X moves from Backlog to Ready for Work, read group from a custom field, fetch all users in the group, for each user - spawn a sub-task). 

If you don’t actually intend for all these people to work on the issue at the same time, and interpret is as “the task should be worked on by one of these people” or “each of these people will work on the task at different stages”, what you may want is self-service assignments. I.e. people pull the tasks they are qualified for once available, based on their skills/user groups.

As part of the team behind Skills for Jira, that's the primary use case we have built it for. The app let's you configure Self-service assignments and gives uses a "Get next task" button to pull the next most important task they are qualified for with 1 click. You stay in control of routing by configuring and prioritizing work queues, attributing queues to user groups, defining priorities, limiting work in progress etc.

[Paul Krueger]

Here's how we've handled this:

1. Create a custom field with the group names.
2. Create a transition from Unassigned (or wherever your issues start) to Assigned and Assigned to Team.
3. When an issue transitions to Assigned to Team, a screen pops prompting you to select the team. Select the appropriate value.
   1. The transition has a validator requiring the team field is populated.
   2. The transition has a post function clearing the assignee field.
4. When an issue transitions to Assigned, a screen pops prompting you to select the Assignee. Select the appropriate assignee.
   
   1. The transition has a post function clearing the team field. 

We don't show the team selection field within the issue view. This prevents people from modifying the team assignment without moving through the transition. An automation rule is configured to trigger on assignee changes when in the Assigned to Team status. If there's an assignee change, it automatically transitions the issue over to Assigned (which also clears the team field).

Here's what this looks like for a simple workflow:

We expect agents to take responsibility for the issue before working on the issue. This is why the issue must move through Assigned before it can move to In Progress / elsewhere in the workflow. 

Finally, to make it all work, you just set up queues that filter based on status. So the DevOps queue filter could look like Status in Assigned to Team AND TeamField = DevOps and Resolution is Empty.

I hope this helps.