User Custom Field Value (multi-user picker) recipients not receiving notification emails

[김대현]

Hi everyone,

We are experiencing an issue where notification emails are not being sent to users selected in a custom field, even though the field is configured as a recipient in our notification scheme.

<Environment>
- Jira Cloud, company-managed project
- Notification scheme: Default Notification Scheme (shared by multiple projects)

<Configuration>
- We created a custom field named "Participants", type: User Picker (multiple users).
- In the notification scheme, for events such as "Work item created", "Work item edited", "Work item resolved", etc., we added the following recipients:
- All Watchers
- Current Assignee
- User Custom Field Value (Participants)

<Problem>
- When a work item is created or edited, the Assignee and Watchers receive email notifications as expected.
- However, the users selected in the "Participants" (multi-user picker) custom field do NOT receive any email notifications.
- The custom field is populated with valid, active users on the work items in question.

<What we have checked>
- The users in the custom field have Browse Projects permission for the project.
- The users are not the ones performing the action (so "You make changes" notification preference should not suppress the emails).
- Their personal notification settings / email preferences appear to be enabled.
- The custom field has the correct context (applies to this project / all issue types).

<Questions>
1. Is there a known limitation or bug where "User Custom Field Value" recipients with a multi-user picker field do not receive notifications?
2. Is there any additional configuration required for multi-user picker fields to work as notification recipients?
3. Has anyone experienced this and found a workaround (e.g., automation rules)?

Any help would be appreciated. Thank you!

[Monika Ambrozowicz_Seibert_]

Hi @김대현, there is one more thing I have in mind. The notification system was originally designed with single-user picker fields in mind, so maybe the fact you're using the multi-user picker fields causes the problem? I would replace it briefly with a single-user picker just to test if it works. 

If you're open to a Marketplace app approach, I'd suggest looking at Awesome Custom Fields, which includes a field type called "Multi User Select & Notify" that's specifically designed to combine user selection with notification delivery in a single field. Rather than relying on the notification scheme's "User Custom Field Value" recipient (which is where your current setup is breaking down), this field type handles the notification trigger directly, which sidesteps the limitation you're hitting.

You'd replace the native "Participants" field with the ACF version, which should integrate with your existing issue views and screens. As a bonus, you'd get plenty of additional useful fields, such as the advance formula field to calculate values based on other fields, color labels, multi-level cascading select field, issue picker, t-shirt size, and many more. 

If you have any questions, I'll be happy to answer them - I am affiliated with the team behind the app and I've tested it in numerous use cases. 

[Karl from Ricksoft]

Hi @김대현 , 

A few things worth checking, in order of how often this actually turns out to be the cause:

1. Field context vs. project scope:  the custom field's context needs to explicitly include the project(s) where you expect the notification to fire. If the context is scoped narrower than you think (e.g. limited to certain issue types or a different set of projects), the field effectively doesn't "exist" for that project even though it's referenced correctly in the notification scheme.
2. Stale field reference in the scheme: if this custom field was ever deleted and recreated (even with the same name), it gets a new field ID under the hood. The notification scheme entry can end up silently pointing at the old, now-invalid ID. Worth removing and re-adding the recipient entry in the notification scheme to force it to bind to the current field ID.
3. Which event you attached it to: double check the specific event (e.g. Issue Created vs. Issue Updated) actually fires when the field gets its value, not just when the issue is created before the field is populated.

#2 is the one that trips people up most since there's no visible error — Jira just quietly drops that recipient from the send list.

Here is a related support documentation.

[Igor Medeiros - Modus Create]

Hi @김대현 

Adding to what Enric sent, for question 3 the automation route works. Each rule takes one trigger, so use Work item created in one rule and Work item updated in another. Set the Send email action's To field to {{issue.Participants.emailAddress}}. That resolves the multi-user picker into addresses and bypasses the notification scheme entirely.

For per-project templates and Multi-User Picker recipients without maintaining rules, our app Notification Assistant for Jira supports user picker custom fields as recipients natively.

Feel free to reach out if you'd like to learn more.

[Enric Font]

Dear @김대현 

This configuration should work.

Things to verify:

1. Is the field actually populated before the notification event fires?

For example:

• Issue Created event
  • If the field is populated by an Automation rule after issue creation, the notification has already been generated.
  • The recipient list is built from the issue state at the moment the event occurs.

This is probably the most common cause.

2. Is the field on the Create/Edit screen?

If the field is not on the Create screen and is later updated by automation or another app, recipients won't exist during the Create event.

3. Is the notification event actually firing?

If you're using:

• custom workflow events
• custom post functions
• custom notification events

make sure the notification scheme is listening to the same event.

4. Issue Security

Besides Browse Project, verify that no Issue Security Level excludes those users.

Atlassian only sends notifications to users who can actually view the issue