Jira Service Management doesn't presently offer a feature like ServiceNow's Assignment Groups, but you can get pretty darn close with a couple of custom fields, an Automation rule, and (optionally) an Insight object type.
If you implement this, then your agents will have to first choose from a set list of Assignment Groups, then your Assignee field will be restricted to a list of users who are members of that Assignment Group. If you implement the optional Insight object type, you'll be able to create queues and filters which show the logged-in user's group's tickets, so you can have a "My group's unassigned open tickets" queue and an "Assigned to my group" dashboard gadget.
We'll walk first through the setup and then discuss how to maintain the membership of assignment groups. Finally we'll discuss a couple of shortcomings of this method.
Assignment groups are not restricted to Jira Service Management and could be implemented in other Jira project types. The optional "my group's issues" filter feature depends on Insight, which depends on Jira Service Management Premium.
Assignment group:
Type: Select List (single choice)
Options: # Names of your assignment groups
- Desktop support
- Network and infrastructure
- Teams for Space development
- etc.
Screens: # Your service desk's screens
- ITSD: Jira Service Management: Incident Create Issue Screen
- ITSD: Jira Service Management: Incident View/Edit Screen
- ITSD: Jira Service Management: Request Fulfilment Create Issue Screen
- ITSD: Jira Service Management: Request Fulfilment View/Edit Issue Screen
- etc.
The assignment group should be set as always visible in each Request Type's issue view. You can also add this to the Request Type's request form (recommended for Changes and Problems).
Assignment group picker:
Type: Group Picker (single group)
Screens: # ! No screens
Type: Insight objects
Insight object field configuration:
Field scope:
Object schema: ITSM # Or your object schema of choice
Filter scope(IQL): objectType = "Assignment group"
User interaction:
Allow search filtering by these attributes:
- Name
Screens: # ! No screens
(Optional)
Object schema: ITSM # Or your object schema of choice
Attributes:
Group:
Type: group
Objects: # Your assignment groups
- Name: Desktop support
Group: Desktop support
- Name: Network and infrastructure
Group: Network and infrastructure
- Name: Teams for Space development
Group: Teams for Space development
- etc.
The names of your Assignment group objects should match your Assignment group custom field options. The group attribute values are the groups set up in Jira User management.
You could expand this further with additional attributes, like the Owner of an Assignment Group, and you might want to link to this object type in other object types in your Insight CMDB, for example, your assets and services.
Your actual assignment groups are set up in Jira User management by a site-admin. Their name should match your Assignment group custom field options. Jira cloud now supports renaming groups, which is nice.
Desktop support:
- # Desktop support agents
Network and infrastructure:
- # Infrastructure agents
Teams for Space development:
- # Teams for Space development agents
etc.
This will cause Jira Service Management to warn that your service desk permissions are incorrectly configured. This can be dismissed.
Assignable User:
- Grant type: Project Role
Value: atlassian-addons-project-access
- Grant type: Group custom field value
Value: Assignment group picker
Rule details:
Scope: All projects
Allow other rule actions to trigger this rule: checked
When:
Value changes for: Assignment group
Then:
- Edit issue fields:
Selected fields:
- Assignment group picker: {{issue.Assignment group}}
- Assignment group object: Name = "{{issue.Assignment group}}"
- Assignee: # empty
Send notifications: not checked
Resolution = Unresolved AND
Assignee IS EMPTY AND
Assignment group object IN iqlFunction(
"Group HAVING user(\"currentUser()\")"
)
Resolved >= -90d AND
"Ticket Category" = Incidents AND
Assignment group object IN iqlFunction(
"Group HAVING user(\"currentUser()\")"
)
Users only ever interact with the Assignment group custom field. The automation rule keeps the other two custom fields aligned.
Membership of assignment groups is maintained in one place only:
On your dashboards and queues, you'll generally want to use the Assignment group custom field, as it can be used in many more places than the group picker and Insight object custom fields.
See [JRACLOUD-3156] Required: Project Group Administrator and [JRACLOUD-77410] Give a set of users the permission to manage other user accounts on this.
However, assignment groups could be provisioned externally via Atlassian Access. In that case, you could assign a friendly name for assignment groups by using the Assignment Group object type as a mapping between the assignment group custom field options and external group names. The automation rule will then need to be adjusted to:
The precise rule steps will be left as an exercise for the reader.
You'll have to choose to either show Assignment group or Assignee on a screen.
This is aside from the limitations of using an automation rule. Even if the group picker custom field was shown to a user, the assignable user REST API endpoint, which is looked up by Jira to show the list of assignable users when you drop down the "Assignee" field, doesn't support being provided with a group custom field value.
Atlassian Support has kindly raised this as a bug. It is more likely that Atlassian delivers a new "Team picker" grant type than any kind of changes to how the "Group picker custom value" grant type works. [JRACLOUD-79760] Unable to assign ticket to a user when creating an issue if the Assignable User permission is set to a user or group picker custom field
We migrated from ServiceNow only two weeks ago with the assistance of GLiNTECH, an Australia-based solution partner, and the core implementation above is completely their work. I added the Insight part but you could just create a queue or filter for each assignment group if you don't have or want to use Insight.
I think this is the best we could expect. The way the assignee field works is hooked deep into the internals of Jira, going all the way back to the osworkflow library that underpins Jira. It won't change any time soon, and this method for Assignment Groups honestly has very little not going for it.
There's a lot that goes into configuring a Jira Service Management service desk to the standard of users who come from ServiceNow. They're very different products, but the Assignment Group feature is one that is genuinely required to operate a Service Desk with more than a dozen agents.
Atlassian may in the future choose to expand the many ways that they have defined a Team (I count four ways: Tempo teams, Advanced Roadmaps shared teams, Compass/Atlassian global teams, and Opsgenie Incident teams) to offer "Assign to a Team" on a service desk. They did for instance enable groups to be configured in approval steps in a workflow, and I don't see why a new "Team picker" grant type can't be added to Project permissions alongside the "Group picker custom field" grant type.
What are your thoughts on this approach to Assignment Groups? How can it be improved, what else would you like to see in relation to assigning tickets to a group?