Hi everyone , 

Filtering for User Picker (multiple fields) custom fields is now available in Jira.

Thank you so much for your input,

Saskia

Hi everyone , 

It's offical ,

Filtering for User Picker (multiple fields) custom fields will be available to everyone by the end of next week (28th Feb). 

Will share an update once it is 100% released, 

Have a great weekend, 

Saskia

53214b82d75d when you say soon can you give a date estimate roughly on this thank you

Hey everyone,

We’re excited to announce that we will soon be rolling out filtering for the User Picker (multiple users) custom field in Jira.

Important announcement: We have also added validation that prevents the User Picker (multiple users) custom field from being saved if the user is no longer inactive, where a filter is enabled on the custom field context.

N.B. This change reflects validation in User Picker (single users) custom fields.

Examples where this may be a problem:

• If the default value of your User Picker (multiple users) custom field is inactive, you won’t be able to create an issue without changing the default value to an active user.
• If you apply a filter, but the default value of the User Picker (multiple users) is not an allowed value after the filter is applied, you won’t be able to create the issue.

We recommend that you check your User Picker (multiple users) custom fields now, so that once this functionality is available, there is no disruption to issue creation.

To locate default value configuration of User Picker (multiple users) custom fields:

Navigate to ⚙️ > Issues > Custom fields > [locate your User Picker (multiple users) custom field] > … > Contexts and default value > Default value. Check that your default value is not set to an inactive user. 

See below, for what it should look like:

If you have any questions, please do not hesitate to reach out,

Saskia van der Peet,

Product Manager, Jira

svanderpeet@atlassian.com

We just realised that when migrating from Jira server to cloud, a custom multi user picker with filtering, the filtering is migrated, and still applies, but because of the above we have no way to modify or remove it.. 

This is problematic..

I know that this is being rolled out for user picker (single and multiple) custom fields here, but hoping that doing this for group pickers is not too far along on the roadmap? This is really hindering a lot of our workflows

684cb16ed833

I see that this issue's status is now In Progress. Is there an anticipated Release Date?

Now that this is coming... this is only on custom fields? So it couldn't be applied to the Assigned To field?

Hello,
looking forward seeing this feature ASAP.
I wonder after releasing it, we will be able to use it with system fields like "request participants". won't we? 

Hey everyone, 

As Carol mentioned, we are going to be picking this feature request up in early 2025. To get the ball rolling, I would love if you could spare a few minutes to chat about this feature. 

Feel free to book a 30-min session here

Looking forward to talking with you, 

Kind Regards, 

Saskia van der Peet

Product Manager, Jira

This is from 2014, it has A LOT of interest.... and its just "in the backlog"?  sometimes I feel like yall are just trolling us. 

I know that for a few customers I support in Jira, the inability on Cloud (whereas Data Center had this feature) to filter the user (multiple) picker options in a custom field is a huge problem. The names are synced with an IdP and it is a compliance audit failure for everything to be visible to any user. Not to mention it is a bad user experience that the relevant users are likely not in the top 25-ish results, so they have to start typing to get their user and fish through hundreds (if not more) of user.

Attempting to apply workflow validators so that only certain user options are allowed to be chosen has been a nightmare and impossible with the out-of-the-box workflow features. Other options like creating multi-select drop-down custom fields which then populate a behind-the-scenes user picker custom field with automation, keeping in mind additions, removals, and changes, is a nightmare and really an unacceptable solution.

The compliance audit piece of this is huge.

Hi Everyone,

Thank you for the continued engagement and interest on this feature request.

As mentioned late last year, this is on our backlog, and we are estimated to pick this up early 2025. We will continue to provide periodical updates. Thank you for your understanding.

Regards

Carol

I am surprised not with that feature was requested 9 years ago and still only "had been considered into medium backlog".

But, rather, with that this feature had to be requested at all.

This is telling a lot:

This is pretty important considering a lot of On Prem clients are being forced to move to the cloud.

We used the capability of group filtering for multi-user picker on Server version and we are quite surprised to see this feature missing on the Cloud version
I supposed that the Cloud version had more features than the server version.

It is common when the Cloud version gives less flexible options than the Server one. But it's uncommon when it completely doesn't give those options that the Server has, less flexible or not.

This feature is an important one to add, it would provide a mitigation to accidental information leakage & limit sharing of PII to non-required roles.

Hello. It has become 2024

This is pretty important considering a lot of On Prem clients are being forced to move to the cloud.

We moved from Jira server to Jira Cloud. We used the capability of group filtering for multi-user picker on Server version and we are quite surprised to see this feature missing on the Cloud version

I supposed that the Cloud version had more features than the server version. Is it possible to add it on Cloud version?

Please implement this or provide a workaround. We also looked in to having a Team-picker instead but that is locked down and only available for the out-of-the-box  Team custom field.

Hi all,

This has been moved to our medium term backlog and we will provide an update when work is started. Thank you for your continued engagement.

Regards

Carol

This would solve an issue for multi customers that complain about seeing too many names of external users in the multi user fields.
Single user is fine and filters for a particular Jira group, multi is just a free for all.

When using Jira as an internal and external tool, this field should allow to filter which information shoudl be shown. Because for internal projects, it has no sense that customers appears at this field. And vice-versa, internal users may are not needed to be shown for customer projects.

So, after 9 years that the request was done, I think it is time to start developing now, as it is a must for data protection.

Hope it is done asap.

That this basic feature has been requested 9 YEARS ago and is still ignored by Atlassian is insane to me.

Can I up vote this 1000 times????  I agree this is more of a 'miss' when rolling out functionality to user picker fields.  Please add this support for multi-user fields.

One thing to note here is that Portal Customers accounts can be exposed potentially creating a Security/PII violation.

This would be true of any portal actions (including allowing users to select others to share their issue with). The filtering of users in a multi-picker would potentially reduce this problem since the only names exposed would be those determined by the filter. 

One thing to note here is that Portal Customers accounts can be exposed potentially creating a Security/PII violation.

PLEASE fix this

Well it seems to me more like a missing feature, than just a simple suggestion.

This should be simple code fix.

Let's go buy the lil' candle Juli

Is this request gonna have his 9th birthday already??

@Anusha Rutnam Thanks! 

Hi 8f86ce8482db I'm not sure why that issue is restricted but I checked it out and the title is misleading. There is no way to filter on the custom field type User Picker (multiple users).

Why is JRACLOUD-80540 restricted? I'd really like to know what the workaround is.

This would be very handy

f3de9f77f778 you may wish to also vote for JSDCLOUD-10055 – Don't show users (or Portal Only Customer) who doesn't have Jira application access to appear on reporters and project roles list

Agree with the comments here - as we have many clients as customers in Service Management, they show up in the multiple user picker, which we are using to tag members of out team with a stake in the issue. Customers can't (and shouldn't) be tagged on our internal Jira issues. 

This is extremely weird that you can do it with single user but can't do it with multiple user picker field. Really annoying. 

this is a must have. 

expectation to have "user picker" multiple in the permission, should also limit only those users can access to project.

Upvoting, this functionality is a must have

created 2014 and still active???

Atlassian, How hard can it be to add filtering in same way you've done it for Single user field?

Would be very useful for a subassignee custom field. A lot of the time I type in an assignee name and I see them pop up about to click them then another name pops up because their email also matches and I accidentally click them.

bump

Waiting for the new functionality

Hmm....need some help? Waiting for the new functionality.

Hm... 7 years... Atlassian timescale... +1

We need this feature, have any news?

I would like to have this functionality as well for multi users! 

https://getsupport.atlassian.com/browse/JST-640474

This is urgently required, currently any internal project with a multi user picker can see all users in our service desk project. That includes "customers" and their email addresses. In addition once added to the multi user picker, customer users can be sent notification emails. 

It is completely painful to set up JSD approvals without having a filtering by group. +1

I've been fiddling with this all morning only to find that it works for single pickers only.  Use case

• We have a Service Desk project with an approval process.
• Any one of several people in a group could approve.  We don't want a default - everyone in the group should get notified.
• We want to hide the approvers field from the requester and let the approval team choose an approver.
• But ... we cannot set multiple default values unless we have a multi user picker.
• But then ... we can't limit the approvers to the group.