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

Jira Automation: Unable to Send Email to User Selected in the Approver Field

Frank Fu

Hi everyone,

I am building a Change Management workflow in Jira Cloud and I am trying to automatically send an approval notification email to the user specified in the Approver field when a Change Request enters the Pending Approval status.

The workflow is:

Open → Impact Assessment → Pending Approval → Approved → Scheduled → Implementation → Validation → Closed

I created an Automation Flow with the following configuration:

Trigger:
Work item transitioned → To status: Pending Approval

Condition:
Work item fields condition → Status equals Pending Approval

Action:
Send email

For the email recipient, I selected the Jira Approver field. The Approver field is a user field, and for my test Change Request (CR-0001) the Approver is set to Frank Fu.

However, the Automation Audit Log reports that the email could not be sent. The error message is similar to:

"Unable to send email to the recipient. This may be due to privacy or recipient account settings."

Earlier, when I was using a custom Approver field, I also encountered an error saying that at least one valid recipient was required. I have since removed the custom field and replaced it with the Jira Approver field, and the field value is correctly set to Frank Fu.

Another observation is that in the Send email → To field, I cannot manually enter an email address. I can only select recipients from the options provided by Jira.

What I am trying to achieve

I would like the Automation to work like this:

Change Request enters Pending Approval
→ Automation is triggered
→ Jira reads the Approver field
→ Email is automatically sent to the Approver

Ideally, I don't want to hard-code an email address because different Change Requests may have different Approvers.

Questions

Is it possible in Jira Cloud Automation to send an email directly to the user selected in the Approver field?
Is there a specific Smart Value or recipient configuration that should be used for a User Picker/Approver field?
Could this error be caused by the recipient user's email privacy settings, Atlassian account settings, or project permissions?
Is there any additional configuration required to allow Automation emails to be sent to individual Jira users?

Any advice or examples of a working configuration would be greatly appreciated.

Thank you!

Accepted answers

Matthew Sinclair

If this is Jira Service Management - you don't need Automation to do that - it does it for you.

But I suspect you are using Jira (Which is why I encourage JSM for this). If this is a Jira "Team Managed" Space where you are using the Approval system - I'm rather surprsied it isn't also doing this for you - seems very strange.

Check Notification Settings to see if something is amiss? Shouldn't have to resort to using Jira Automation. But in any case…

You should be able to map the email address with this smart value:

{{Approver.emailAddress}}

Reference: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/

Also as an afterthought - you may want to check the user and see if they have any specific settings on their personal notification settings to see if they are blocking anything - just like the error says.

If you are an Org Admin you won't be able to see this by design - only the User can do that. (Even with the log in as user trick).

Also you can't email "Atlassian Teams" if you ask - that's a feature request not yet implemented. (Been there done that)

Hopefully this removes the road block.

Ballon Apps

Adding to Matthew's answer: one thing worth checking is the approver's email visibility. If it's set to "Only you and admins" (Atlassian account > Profile and visibility), the emailAddress smart value comes back empty, so the rule has no address to send to.

Easy to test: add a Log action before Send email with {{Approver.emailAddress}} and run the rule once. If the audit log shows nothing, it's that setting, and the approver can change it in their own profile. If the address does show up, at least you've ruled this one out.

Sami Shaik

@Frank Fu ,

@Matthew Sinclair and @Ballon Apps have the two checks that matter (the smart value, and the recipient's email visibility). One thing explains your other symptom, "I cannot manually enter an email address":

You are on the deprecated action. Atlassian's automation actions reference marks Send email as deprecated and points to Send customized email, which takes "user fields or groups" from the dropdown and also lets you "enter smart values, or email addresses". That is the action your rule should be on. Swap it, and the To field accepts all three of these:

the Approver user field picked from the dropdown (simplest, and it respects the user's notification settings);
the smart value {{issue.Approver.emailAddress}}, with the issue. prefix (or {{issue.customfield_NNNNN.emailAddress}} using the field's ID, which survives a rename);
a typed address, for testing.

Then isolate the failure in the audit log. Put a Log action with {{issue.Approver.emailAddress}} before the email, as Ballon Apps suggested. Three outcomes:

Empty: the approver's email visibility is set to only them and admins (Atlassian account, Profile and visibility). Only they can change it. Picking the user field from the dropdown instead of the smart value sidesteps this, because automation then addresses the account rather than reading the address.
Address present, still "unable to send": retry once an hour later before touching config. This exact error text has shown up during Atlassian-side incidents on the email action (Support confirmed one in February 2026 on a thread here), and there was a tracked bug for portal-only accounts, AUTO-2330, fixed in May 2026. A rule that fails once and passes unchanged later was never your config.
Address present, sends from the new action: done.

Two boundaries: Send customized email is not available on HIPAA-compliant sites, and if your approver is an Atlassian Team rather than a person, neither action can email it (Matthew's point).

And his first point is the one I would still take seriously: if these change requests live in Jira Service Management, approvals notify approvers natively and you can delete the rule.

All comments

Matthew Sinclair

If this is Jira Service Management - you don't need Automation to do that - it does it for you.

Check Notification Settings to see if something is amiss? Shouldn't have to resort to using Jira Automation. But in any case…

You should be able to map the email address with this smart value:

{{Approver.emailAddress}}

Reference: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-users/

If you are an Org Admin you won't be able to see this by design - only the User can do that. (Even with the log in as user trick).

Also you can't email "Atlassian Teams" if you ask - that's a feature request not yet implemented. (Been there done that)

Hopefully this removes the road block.

Ballon Apps

Sami Shaik

@Frank Fu ,

the Approver user field picked from the dropdown (simplest, and it respects the user's notification settings);
the smart value {{issue.Approver.emailAddress}}, with the issue. prefix (or {{issue.customfield_NNNNN.emailAddress}} using the field's ID, which survives a rename);
a typed address, for testing.

Then isolate the failure in the audit log. Put a Log action with {{issue.Approver.emailAddress}} before the email, as Ballon Apps suggested. Three outcomes:

Empty: the approver's email visibility is set to only them and admins (Atlassian account, Profile and visibility). Only they can change it. Picking the user field from the dropdown instead of the smart value sidesteps this, because automation then addresses the account rather than reading the address.
Address present, still "unable to send": retry once an hour later before touching config. This exact error text has shown up during Atlassian-side incidents on the email action (Support confirmed one in February 2026 on a thread here), and there was a tracked bug for portal-only accounts, AUTO-2330, fixed in May 2026. A rule that fails once and passes unchanged later was never your config.
Address present, sends from the new action: done.

Two boundaries: Send customized email is not available on HIPAA-compliant sites, and if your approver is an Atlassian Team rather than a person, neither action can email it (Matthew's point).

And his first point is the one I would still take seriously: if these change requests live in Jira Service Management, approvals notify approvers natively and you can delete the rule.

Matthew Sinclair

To add to Sami's goodies

You may need to append "trigger"

{{triggerIssue.Approver.emailAddress}}

As your trigger may or may not be playing nice context wise.

I may or may not have spent too much time in Jira Automation. 😁

Also if you have Rovo Chat sitting there - you may want to abuse it a little bit to help solve the mystery.

I still say that Its a little surprising that the "Approval" system which does in-fact live in Jira (Team Managed only) has no notification system built in.

Frank Fu

Update: Thank you everyone!

Thank you @Matthew Sinclair , @Ballon Apps , and @Sami Shaik for the detailed and very helpful replies . I followed all three of your suggestions and wanted to share the outcome:

Email visibility check — I went to my Atlassian account → Profile and visibility → Email address, and changed it from "Only you and admins" to "Anyone". This was indeed the first issue — the Approvers field was returning an empty address because of this privacy setting.
Switched to "Send customized email" — I confirmed the action was already on the newer "Send customized email" action (not the deprecated "Send email"). I also tried removing the {{issue.Approvers.emailAddress}} smart value entirely and typing in the recipient's email address manually as a direct test.
Tested with a real transition — I disabled then re-enabled the rule, transitioned the work item from "Impact Assessment" → "Pending Approval" multiple times, and checked the Audit log after each run.

Result: Even after all of the above, every execution still fails with the same message:

"We couldn't send emails to any recipients. This may be for data privacy or recipient email account configuration reasons."

Since the manual email address test also fails, it seems this is a platform-level limitation on my Jira Cloud site (which appears to be on the Free plan) rather than a configuration issue on my end. I'll accept this and use Jira's in-product notifications (the bell icon + Approval cards) as the primary channel, and notify approvers via Gmail manually for external stakeholders.

Your feedback was still incredibly useful — it ruled out several configuration mistakes and gave me confidence the issue isn't on my side. Really appreciate the time you took to help a community member.

Best regards,
Frank Fu

Frank Fu

I'm on the Jira Cloud Free plan. I don't know if this is related

Sami Shaik

Thanks for accepting, @Frank Fu , and for the detail. Two parts.

Is the Free plan the cause? Not according to anything Atlassian publishes. The automation actions reference gives Free one email limit, 100 emails in 24 hours, and Explore Jira Cloud plans gives Jira Free 150 automation steps per month. Hitting the step allowance would stop the rule with an allowance message, not “couldn’t send emails”. So treat Free as unproven, not as the answer.

What to check next, in order:

The audit log detail. Expand the failed Send customized email step; the detail line under the summary usually names the rejected address or says “no valid recipients”. Post that line here (mask the address).
A minimal rule. Manual trigger, one action, Send customized email, To = your own address typed in, subject “test”. If that fails, the problem is the site’s email sending, not your approver logic. If it sends, go back to the real rule and compare the To field.
Steps used. System, Global automation, Usage. If you are at 150 of 150 the rule is not running at all, which looks similar from the outside.
The From address. If an org admin added a custom sender at admin.atlassian.com, switch it back to the default jira@ sender for the test; a custom sender with incomplete domain setup will fail silently for every recipient.

One honest boundary: Free plans get Community support, not Atlassian Support tickets, so this thread is the right place to keep the trail. Post the audit log line and we will go from there.

Matthew Sinclair

Agreed - this is not a free plan limitation.
And I still don't understand how the approval system isn't sending notices.

Bitrupt - Software Development

Hi Frank Fu,

Yes, you can use a dynamic recipient in Jira Cloud Automation. Try using the Send email action with the Approver field’s smart value, for example {{issue.Approver.emailAddress}} (the exact smart value depends on your field configuration).

If the email still fails, check whether the smart value resolves to an actual email address and whether the recipient’s email is accessible under Atlassian’s privacy settings. You can also review the automation audit log for more details.