Jira Automation: Merge accountIds from Project Roles and notify only active users

[Raissa Nepomuceno Epaminondas]

Hi everyone,

I’m trying to implement a Jira Cloud Automation rule to notify leadership users when the percentage of Bugs in the backlog exceeds a threshold.

The email recipients must be dynamically retrieved from Project Roles.

Main Requirement

The automation must:

• Retrieve users from multiple Project Roles

• Merge all returned accountIds into a single list

• Remove duplicated users

• Validate which users are ACTIVE

• Retrieve email addresses only for ACTIVE users

• Send emails only to ACTIVE users

• If ALL users are inactive, send email to a fallback user

---

Current Automation Logic

What I tried so far:

GET Role PO (/rest/api/3/project/{{project.id}}/role/12067)
↓
GET Role SM (/rest/api/3/project/{{project.id}}/role/12064)
↓
Advanced Branch:
{{webResponses.body.actors.actorUser.accountId}}
↓
GET Admin API (https://api.atlassian.com/admin/v2/orgs/{orgId}/directories/{directoryId}/users/{{getAccountId}})
↓
Condition:
{{webResponse.body.data.status}}
↓
Send Email:
{{webResponse.body.data.email}}
ELSE
Send email to fallback user

Unfortunately, this is not working correctly.

Inside the Advanced Branch, {{getAccountId}} is coming empty in my environment.

Because of that, the Admin API request becomes:

/users/

instead of:

/users/{{accountId}}

which causes the API to return the first page of users from User Management.

After investigating with Atlassian Support, I now understand why this behavior happens.

---

Additional Attempts

I also tested:

{{ActorsAccountIdPO.concat(ActorsAccountIdSM)}}

but the variables seem to behave like strings instead of arrays.

Result example:

[id1][id2],[id3]

instead of a proper merged list.

I also tried a simpler merge approach:

{{accountIdPO}},{{accountIdSM}}

This worked partially for iteration purposes, but:

• I could not identify a reliable way to remove duplicated users

• the array/string behavior in Jira Automation seems inconsistent

The most stable workaround I found so far was:

{{allAccountIds.split(",").removeEmpty().distinct()}}

---

Important Constraint

I cannot use:

/rest/api/3/user?accountId={{getAccountId}}

because in our Jira Cloud environment the emailAddress field is NOT returned due to privacy restrictions.

Because of this, I had to use the Admin API instead:

https://api.atlassian.com/admin/v2/orgs/{orgId}/directories/{directoryId}/users/{{getAccountId}}

since this endpoint returns:

• email

• active/inactive status

---

Main Question

Is it actually possible to implement this logic reliably using only Jira Automation Cloud?

More specifically:

• What is the best pattern to merge accountIds from multiple Project Role requests?

• How can duplicated users be removed safely?

• What is the best approach to validate only ACTIVE users?

• How would you implement the fallback logic if ALL users are inactive?

Or would you recommend another approach instead, such as:

• Forge

• External API/service

Any guidance or architecture suggestions would be greatly appreciated.

Thanks!

[Pablo Vergara]

Hi @Raissa Nepomuceno Epaminondas 

Welcome to the community forums!

This was quite an interesting and challenging scenario. I wasn't able to find an out-of-the-box solution without using REST API requests with Automation for Jira, so that the approach will use a few different endpoints.

My tested configuration example is shown in the captures below. Just consider the proposed solution uses a single project role, but that can be changed later on if needed, adding new variables and a final one to compound all the extracted members' account IDs.

I hope this helps you as a guideline!

- Pablo Vergara / SSE - ServiceRocket

[Raissa Nepomuceno Epaminondas]

Hi @Pablo Vergara ,

Thank you very much for taking the time to analyze this scenario and for sharing your example configuration!

Yes, I believe the main problem in my case is currently inside the Advanced Branch logic itself.

My current flow is basically:

GET Role PO
↓
Store accountId actors PO in variable
↓
GET Role SM
↓
Store accountId actors SM in variable

↓
Store all accountIds
↓
Verify if at least one accountId exists

↓
Advanced Branch: {{allAccountIds.split(",")}}
↓
GET Admin API
↓
Validate active user
↓
Send Email
↓
ELSE 
↓
Send fallback user email

However, the iteration is not working correctly the way I configured it.

I still have concerns regarding the reliability of deduplication, especially in scenarios where the same user belongs to both Project Roles.

At the moment, I’m not fully confident that Jira Automation handles array manipulation and deduplication consistently enough for this type of logic.

Thanks again for sharing your example — it was very helpful as a reference!

[Bill Sheboy]

Hi @Raissa Nepomuceno Epaminondas 

I recommend first extracting all the accountId values from the relevant calls into Created Variables to consolidate them, and handle any nested list problems.  Then, using split() back into a list before adding the distinct function.

Regarding your requirement to "If ALL users are inactive, send email to a fallback user", that may not be possible with a single automation rule using the Advanced Branch structure you show.  The reason is such branches execute in parallel and asynchronously with no guarantee of when the branch will complete up until the last step of the rule.  Thus, the rule could not set a value / indicator within the branch for detection later to fallback to another user.

Returning to your original statement:

I’m trying to implement a Jira Cloud Automation rule to notify leadership users when the percentage of Bugs in the backlog exceeds a threshold.

Have you considered using JQL and perhaps some dashboard gadgets, and a user group for the people?  Then rather than a "push", try a "pull" and let them look for the threshold / values.

Kind regards,
Bill

[Raissa Nepomuceno Epaminondas]

Hi @Bill Sheboy ,

Thank you very much for the detailed explanation!

Your point about extracting and consolidating the accountIds into Created Variables before the Advanced Branch makes a lot of sense, and that is actually the direction I started moving toward after the issues I had using `webResponses` directly.

I also appreciate the explanation regarding the asynchronous behavior of Advanced Branches.

My current requirement is:

* notify only ACTIVE users
* and if ALL users are inactive, send the email to a fallback user

But as you explained, since the branch executions run in parallel/asynchronously, the rule cannot reliably determine at the end whether at least one active user was found across all iterations.

That clarification helped me understand why the behavior has been inconsistent during testing.

Regarding the dashboard suggestion, I completely understand the idea of using a “pull” model instead of “push”.
However, in this particular case, the business requirement explicitly requires proactive email notifications whenever the number/percentage of critical/high/medium/low bugs exceeds the configured threshold.

So unfortunately dashboards alone would probably not satisfy the operational expectation, since they would require active daily monitoring by the leadership team.

Thank you again for the insights, your explanation about the asynchronous branch behavior was extremely helpful!

[Bill Sheboy]

Hi @Raissa Nepomuceno Epaminondas 

Thanks for the additional information!  You may want to check with your Jira Product Admin to learn if you have any marketplace apps / addons, such as for reporting which can do the pushes...or which extend the features of JQL to detect the user status.

Another option would be to build your own external app, such as using the REST API endpoints or with Forge.

[Marcos Sanchez]

Hello @Raissa Nepomuceno Epaminondas

As far as I can see on a first look, getAccountId is empty because you are retrieving

{{webResponses.body.actors.actorUser.accountId}}

instead of 

{{webResponse.body.actors.actorUser.accountId}}

the API call on the automation returns webResponse, without the 's'. In fact, I can see that you are properly using it on the rest of the flow, so it should work as expected then.

On the other hand, I'm not 100% sure that Automation for Jira maybe can't do that data process that you require. Specially the status checks and the deduplication.

If you are familiar with Forge, a small Forge app would fit greatly. If not, maybe you could develop some Python script on a Jenkins job or similar and run it as a service.

Regards!

[Raissa Nepomuceno Epaminondas]

Hello @Marcos Sanchez !

However, because I needed to merge the results from both Project Role requests, Atlassian Support recommended using webResponses (with “s”) to access all previous web request responses together inside the same rule and webResponses.body is actually returning data correctly from both requests.

I added a Log Action with:

webResponses Body: {{webResponses.body}}

 

So at this point I believe the challenge is more related to how Jira Automation handles array parsing / iteration from merged webResponses rather than the API response itself.

I also agree with your point that Automation may not be the ideal tool for this level of data processing and deduplication logic. :/ 

Thanks a lot for your help and insights!

[Igor Medeiros - Modus Create]

Hi @Raissa Nepomuceno Epaminondas 

The array behavior you're hitting is a known Automation limitation. Smart values lose array typing across web request branches, so `concat` collapses to strings. Your `split(",").removeEmpty().distinct()` pattern is the canonical workaround inside pure Automation.

For active-user filtering without the Admin API hop, our app Notification Assistant for Jira takes Project Roles as a native recipient type. It only emails licensed, active users, and CRON triggers cover the threshold check.

Feel free to reach out if you'd like to see the setup.

[Raissa Nepomuceno Epaminondas]

Hi @Igor Medeiros - Modus Create ,

Thank you very much for the clarification!

This actually helps a lot because it confirms that the behavior I’m seeing is indeed related to a Jira Automation limitation regarding array handling and web request branching, and not necessarily an issue with my logic itself.

I also appreciate you sharing the Notification Assistant approach. At the moment we are prioritizing a native/free solution first.

But it is definitely good to know that there are Marketplace solutions.

Thanks again for the help and insights!