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; } } }

Custom field group picker shouldn't show all the groups in Jira (JSM)

Johannes Isacsson

Hi,

We are currently doing a proof of concept of JSM to see if it's a fit for our company regarding service requests.

In our current system you can set up different type of groups as you'd like and specify which users should be a part of each group. That means that when you choose for example "Finance" as a group you can only pick assignee X, Y or Z. No one else.

I've read several posts about similar things here on the forum, most of them a few years old now, but I can't figure out how to do it in JSM.

We are using a company based space in general (but for JSM it says "Service Management" though, not sure about that one).

1. I've set up a Group picker as a custom field (called "Handläggargrupp 2.0"), but when i'm searching in it ALL the groups in our entire Jira appears… (below is just some of the groups appearing)

2. I've adjusted the permission under Assignable user:

The problem appears at step 1 though as we don't want all the groups in Jira to appear, just the specifik support groups that I want to create in JSM.

I must be missing something here, because this feels like standard functionality in systems handling support requests?

I've read this thread and thought that was the answer, but it appears to be team-based and not company based (?):
How to assign issues to users based on the group selection | Jira and Jira Service Management | Atlassian Support

—

As I was writing this I thought of a potential work around. Is it possible to:
1. Still have the Group picker custom field showing all the groups in Jira
2. Create a custom field Select list (single choice) with the same group names that I want specified in the group picker
3. Create an automation rule that says that the value that is in Select list should be duplicated to Group picker. Group picker should always be hidden.
4. In that way the Group picker will always follow the selected group and restrict which assignees you can choose from.

I would really appreaciate if someone could discuss this with me as soon as possible. Thank you so much!

Accepted answers

Shaik Riyaz

Hi @Johannes Isacsson,

Yes, your workaround is completely viable and the standard way to solve this in Jira Cloud.

Because native Group Picker custom fields cannot be restricted by context/options, syncing a Select List (single choice) to a hidden Group Picker via Jira Automation works reliably:

Select List (single choice): Add only the relevant support groups as options and place this on your agent/request screens.
Group Picker (hidden): Keep this off the main screens and map it in your Permission Scheme under Assignable User (User / Group Custom Field).
Automation Rule:
- Trigger: Field value changed (Support Team) / Issue created
- Action: Set the hidden Group Picker value based on the selected dropdown option (via simple If/Else blocks or matching smart values).

One thing to keep in mind: Automation runs asynchronously (1–2 seconds after save). When triaging existing tickets or working from queues, agents will see the Assignee dropdown restricted to only users in that group once the rule executes.

Thanks!!

Mihai_LeanZero

Hi @Johannes Isacsson, with Assets and automation alone, yes, all 10 still show. Only the permission route Shaik Riyaz described narrows the list. The article you linked (https://support.atlassian.com/jira/kb/how-to-assign-issues-to-users-based-on-the-group-selection/) is that same setup, group-based and for company-managed spaces.

I tested it today on a company-managed JSM space. The Assignee list followed the field, and an empty field meant nobody could be assigned. The test site has one licensed agent, so a real team split wasn't possible.

The group field must be the only Assignable user grant, so remove application access and the Service Desk Team role from it.

Keep the picker on the work type's Edit screen. Per this KB (https://support.atlassian.com/jira/kb/some-of-the-set-fields-arent-available-error-in-jira-cloud-automation/) the rule can't set a field that isn't there.

Bulk edit is the catch. Per JRACLOUD-95253 (https://jira.atlassian.com/browse/JRACLOUD-95253) it can't set the assignee with this permission.

Run Permission helper for an agent who shouldn't show.

Shaik Riyaz

Hi @Johannes Isacsson ,

Because standard field mapping won't let you paste smart values into a Group Picker, use the Additional fields (JSON) option in the Edit action:

Trigger: Field value changed → monitor Handläggargrupp
Action: Edit work item fields
- Leave the standard field selector empty.
- Expand More options at the bottom.
- In Additional fields, paste:

{ "fields": { "customfield_xxxxx": { "name": "{{issue.Handläggargrupp.value}}" } }}

(Replace customfield_xxxxx with your Group Picker's custom field ID, e.g., customfield_10042.)

Note: The dropdown option text must match the Jira group name 100% identically (including exact spelling/casing). If it's a multiple-group picker, wrap the object inside square brackets [ ... ].

Thnaks!!

Mertcan Karabaş (WERARE)

Hi @Johannes Isacsson ,

Ciro’s single rule, with Mihai’s tweak of dropping the “is not empty” check, is the way to go for copying the group. Before real requests start coming in through the portal, three more things are worth setting up:

1. Make sure the default assignee is Unassigned
Check Space settings → Details → Default assignee. Now that Assignable User comes only from Handläggargrupp 2.0, nobody can be assigned at the moment a request is created, because the rule fills in the group a second later. If the default assignee is the project lead, creating requests can fail with “The default assignee does NOT have ASSIGNABLE permission…”. Atlassian’s KB on it: Agents and customers can’t raise requests in a JSM Cloud project

2. Clear the assignee when the group changes
Jira doesn’t remove an assignee who stops being assignable. If an agent moves a request from Finance to Systemförvaltning, it stays with the Finance agent. In the same rule, after Edit work item fields, add:

a {{smart values}} condition: first value {{fieldChange.fromString}}, condition does not equal, second value left empty
Assign work item → Unassigned

On a new request there’s no previous value, so only the copy runs. When a request is moved, it’s also unassigned and waits for the new team. Clearing the select counts as a move too, which is what you want, since nobody can be assigned then.

3. Hide the group picker without taking it off the screen
As Mihai said, the rule can only set the field while it’s on the Edit screen. To keep it out of sight anyway, open each request type, go to the Issue view tab (it may say Work item view), drag Handläggargrupp 2.0 out of the layout into the field panel and save. Also leave it off the request form. It’s then hidden for that request type but still on the screen for the rule.

If you haven’t already, one queue per handling group (filtered on Handläggargrupp) gives each team its own list.

Keeping your support groups organized
Full disclosure: I work for WERARE, and we make https://marketplace.atlassian.com/apps/1229724/group-manager . It won’t change what the native group picker lists, and memberships are still managed in Atlassian Administration, so the setup above is still what limits the Assignee. What it adds is an overview of the groups themselves. You give groups your own properties (for example Group type = Support) and a group leader, then save a view that lists only your handling groups with their members, and export it to Excel or CSV when needed. Agents and team leads can check who’s in which group without admin rights. There’s a free trial if it’s useful during the PoC.

Good luck, and feel free to ask here if the rule misbehaves!

All comments

Marc -Devoteam-

Hi @Johannes Isacsson

Welcome to the community

Indeed this can't be limited, see also JRACLOUD-96894

If you are on a premium plan, you could use assets for this.

Create your required groups as asset objects and add a status attribute to each object, you could even add a group attribute to link the actual group.

Create a custom assets field that only shows groups that are active, use this field.

Other option is o start using Teams and not groups.

Johannes Isacsson

Thank you for your reply.

We are on the Standard plan. The Premium Plan is too expensive for us so it's not an option with Assets in this case.

Could you further develop your thought on how to use Teams instead of Groups to solve this?

When a customer sends in a service request via the Portal, how will we be able to say that if the customer has chosen "Finance" it will go to the Finance Team (and not Group) with specific users? And here you should also be able to switch Team and assignee.
I can't find any field for this when trying to create custom fields.

Marc -Devoteam-

Team is not a custom field, but a platform option.

See https://support.atlassian.com/platform-experiences/docs/using-atlassian-teams-in-jira-projects/ for more infromation.

All Team information should be available here; https://support.atlassian.com/platform-experiences/docs/work-with-atlassian-teams-across-your-products/

Ciro

Hello. One update on the plan part, since it may change your options: Assets isn't Premium-only anymore. Atlassian rolled it out to Service Collection Standard this year (all Standard customers were to be enabled by March 12, 2026), with a 5,000-object allowance included. Check whether Assets shows up in your app switcher; if it does, the Assets route from the answer above is open to you on Standard.

Rough shape for your Finance example:

An object type, e.g. Handling group, with one object per support group, a Users attribute with the people who can handle it, and a Status attribute so you can retire groups.
An Assets object custom field on the request type, filtered to active objects. Only your support groups show up, not every group in Jira.
An Automation rule on work item created that reads the chosen object's users and assigns one of them, or routes the request to that group's queue.

The Assignee field itself still can't be limited to those people, so the rule (or the agents) has to do that part.

Johannes Isacsson

Much appreciated information, thank you for that!

Just to clarify what your last sentence really mean for us if we choose the Assets option:

If we for example have three support teams:
Finance: 3 unique agents
System: 4 unique agents
Info.sequrity: 3 unique agents

With the automation rule we will be able to get the work item to a specific team (via Assets), for example a work item towards the Finance support team of 3 people. When they then want to choose which agent that will reply to the customer in the assignee field, they will still see 10 different agents (Finance, System, Info.sequrity)?

Shaik Riyaz

Hi @Johannes Isacsson,

Yes, your workaround is completely viable and the standard way to solve this in Jira Cloud.

Because native Group Picker custom fields cannot be restricted by context/options, syncing a Select List (single choice) to a hidden Group Picker via Jira Automation works reliably:

Select List (single choice): Add only the relevant support groups as options and place this on your agent/request screens.
Group Picker (hidden): Keep this off the main screens and map it in your Permission Scheme under Assignable User (User / Group Custom Field).
Automation Rule:
- Trigger: Field value changed (Support Team) / Issue created
- Action: Set the hidden Group Picker value based on the selected dropdown option (via simple If/Else blocks or matching smart values).

Mihai_LeanZero

The group field must be the only Assignable user grant, so remove application access and the Service Desk Team role from it.

Bulk edit is the catch. Per JRACLOUD-95253 (https://jira.atlassian.com/browse/JRACLOUD-95253) it can't set the assignee with this permission.

Run Permission helper for an agent who shouldn't show.

Johannes Isacsson

@Mihai_LeanZero , @Shaik Riyaz

Thank you both for the awesome answers! I've read them carefully and they have helped me a lot in understanding the set up.

I get stuck on the automation rule unfortunately. I do believe that my lack of knowledge is the primary cause though.

The rule I get to work so far is set up as below, but it feels wrong in how to do it…

Value changes for
Fields to monitor for changes: Select field (Handling group, or Handläggargrupp in my case)
Change type: Any changes to the field value

If matches
Run action if… Atleast one condition matches
Condition: Handling group equals Systemförvaltning (one of the handling groups)

Edit work item fields
Choose fields to set… Group picker
Choose value "Systemförvaltning"

—

This rule will copy the field from select field to group picker correctly, but only for one value (Systemförvaltning). I want one automation rule to look at the select field and copy it to group picker regardless of the value set. In my set up I guess I have to create a lot of similar automation rules but with different values that it looks for (one automation rule for one handling group), and this just feels wrong.

Will you be so kind and share your knowledge and automation rules in this case to get it correctly?

Ciro

Hi! You can do it with one rule and no If block: let the edit action take the group name straight from the select field.

Keep your trigger and remove the If condition.
In Edit work item fields, leave "Choose fields to set" empty, open More options and put this in Additional fields: {"fields": {"customfield_GROUP": {"name": "{{issue.customfield_SELECT.value}}"}}} with your two field IDs in place of GROUP (the group picker) and SELECT (Handläggargrupp). That works as long as each option is spelled exactly like its group.
If the names differ (option "Systemförvaltning", group "jsm-systemforvaltning", say), add a Create lookup table action before the edit, call it groups, one row per option (key = option, value = group name), and use {{groups.get(issue.customfield_SELECT.value)}} inside the JSON instead.

Run one test and open the rule's audit log: it shows whether the group was set, or why not. A Handläggargrupp is not empty condition right after the trigger stops the rule from failing when someone clears the field.

And a correction to my earlier reply: the Assignee list can be narrowed after all, with the permission route described above.

Mihai_LeanZero

Hi @Johannes Isacsson,

Ciro's single rule works as written, so you don't need one rule per handling group. I tested it today on a test site with your trigger and his JSON in Additional fields. Options with spaces and with ö mapped fine. So did his lookup table.

I'd drop the "is not empty" condition he suggested, though. When I cleared the select without it, the rule ran fine and cleared the group picker too. With it, the old group stays. Its people can still be assigned.

If a group doesn't update, look in the rule's audit log for "Could not find group with name", which is what I got when an option was spelled differently from its group, and then either fix the spelling or add that option to the lookup table.

The JSON format is here: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/

Ciro

Good catch, and thanks for testing it. Agreed, drop the "is not empty" condition: without it, clearing the select also clears the group picker. With it, the old group stays in the field and its people remain assignable, which is exactly what this setup is meant to prevent.

Shaik Riyaz

Hi @Johannes Isacsson ,

Because standard field mapping won't let you paste smart values into a Group Picker, use the Additional fields (JSON) option in the Edit action:

Trigger: Field value changed → monitor Handläggargrupp
Action: Edit work item fields
- Leave the standard field selector empty.
- Expand More options at the bottom.
- In Additional fields, paste:

{ "fields": { "customfield_xxxxx": { "name": "{{issue.Handläggargrupp.value}}" } }}

(Replace customfield_xxxxx with your Group Picker's custom field ID, e.g., customfield_10042.)

Note: The dropdown option text must match the Jira group name 100% identically (including exact spelling/casing). If it's a multiple-group picker, wrap the object inside square brackets [ ... ].

Thnaks!!

Johannes Isacsson

Hi @Ciro / @Mihai_LeanZero / @Shaik Riyaz

Thank you all again for your answers. With your detailed help I was able to make it work with the Additional fields.

For my and others understanding of the rule, how come that I can't use the same automation rule with the additional field info as described above if I want to copy a field in the same way as above but from a Select list (single choice) to another Select list (single choice) where the value is exactly the same?
So it is nearly the same case as the original one with Select list → Group picker but instead it's Select list → Select list.

When testing it (just replacing customfield_ID under additional field) the field doesn't copy in the same way as the Group picker case.

Mihai_LeanZero

Hi @Johannes Isacsson,

A group is found by "name", but a select option is found by "value", so swap name for value and the same rule works:

{"fields":{"customfield_TARGET":{"value":"{{issue.customfield_SOURCE.value}}"}}}

Ciro's and Shaik's JSON was right for the group picker. If you open the rule's audit log you'll probably see "Specify a valid 'id' or 'name'" for your field. That's confusing, because name doesn't work on a select.

Select to select doesn't need JSON at all:
1. In Edit work item fields, pick the target select.
2. Click the ... next to it and choose Copy.
3. Click "Copy from Work item" and set "Field to copy value from" to the source select.

The option text has to exist in the target field's options too. I tested both routes today with an option that was only in the source. The value JSON logged "Specify a valid value" and kept the old value, while Copy from logged SUCCESS and silently emptied the target. With that route an empty target is the sign to look for.

The single select example is on the advanced field editing page:
https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/

This KB uses the same "value" pattern in Additional fields:
https://support.atlassian.com/jira/kb/automation-rule-or-updating-single-select-custom-field-with-value-in-the/

Johannes Isacsson

@Mihai_LeanZero

Aha! Maybe I should have figured out that one by myself. It worked out perfectly. Top notch help, thank you again!

Mertcan Karabaş (WERARE)

Hi @Johannes Isacsson ,

a {{smart values}} condition: first value {{fieldChange.fromString}}, condition does not equal, second value left empty
Assign work item → Unassigned

If you haven’t already, one queue per handling group (filtered on Handläggargrupp) gives each team its own list.

Good luck, and feel free to ask here if the rule misbehaves!

Johannes Isacsson

Hi @Mertcan Karabaş (WERARE)

Great contribution to the post.
Number 1. was already default Unassigned, but 2. and 3. was something I hadn't thought about yet.
Especially 2. was definitely something I would have encountered soon enough and never known how to solve it - so thank you for that.
The rule works as expected with your addition to it.

I will look into the Group Manager addon in the future when we've come further.

Best regards

Welcome!

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

Quick Links

Find more posts tagged with

jira-service-management