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

For each Release Automation

Anthony Pugliese

Hi All,

i am creating an automation to send Release approver emails, which i have now setup correctly based on the document below in an exact manner.

How to send emails Approvers of Jira release using Automation for Jira | Jira and Jira Service Management | Atlassian Support

what i am trying to figure out is an addition

1. when I have multiple release approvers, i want to be able to list out all the approvers in an email content so the approver knows there is multiple approvers.
and if possible, send a single email rather than sending each approver a separate email

currently i have the branch "For each" smart value to obtain a single account id via a web request (as stated in the document above), which then sends an email to the account
if there is multiple approvers, it will send an individual email each.

this part is working fine but wish to enhance this a bit more

unsure if there is a way to consolidate the branching so i can send only 1 email to all approvers. if possible, contain the 'for each' output into a variable so that i can reference it to send a single email rather than multiple?

Accepted answers

Bill Sheboy

Hi @Anthony Pugliese

For more context, would you please post images of the following:

your complete rule, in a single image for continuity
the branch
the audit log details showing a rule execution

Until we see those...

I suspect the challenge is because the email address is not provided directly with the approvers, each must be found individually (with the branching) and so cannot be gathered together for a single email. Seeing the specifics of your rule will confirm this so the community can suggest options. Thanks!

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Anthony Pugliese

For more context, would you please post images of the following:

your complete rule, in a single image for continuity
the branch
the audit log details showing a rule execution

Until we see those...

Kind regards,
Bill

Anthony Pugliese

thanks Bill

the rule is setup as per the image below. taken from the document as my current rule has a few extra steps and variables that i am trying to figure out on something else

Screenshot_2025-02-03_at_7.02.05_PM

my audit log looks like this for a successful run. ive blacked out the aspects around create variable step im including and accountID data

Bill Sheboy

Thanks for the additional information, @Anthony Pugliese

Unfortunately, the {{issue.fixVersions}} smart value does not include the approver information...and, when the approvers are found using the Get Version endpoint, that does not include their email addresses either.

And...the Bulk Get Users endpoint does not return all email addresses, and the Get User Email Bulk endpoint cannot be called from a rule (only from Forge, an app, etc.)

After a bit of searching, I could not find any suggestions in JAC backlog for this need.

Let's consider a workaround using a placeholder work item...The general idea is to duplicate the approver users in a custom field in the placeholder work item for later use.

Create a global / company managed, custom field of type User Picker (multiple users), perhaps named Release Approvers. This needs to be a global field, even if you are using a team-managed project because People fields do not provide emails addresses to rules.
Add that custom field to one of the work item types in your project / space
create several automation rules...
- When a version / release is created, add a work item which a Summary to indicate the version id and name
- When a version / release is updated (based on your original rule)...
  - Get the approvers for the version using the REST API endpoint
  - Use Lookup Work Items with JQL to confirm the work item exists
  - Branch with JQL to that work item
    - Update the custom field to be the approvers list using the account ID values
    - Re-fetch the work item to load the user's data
    - Now we can use the email address from that custom field!
- When a version is released, unreleased, or deleted, add addition rules with those triggers to decide what you want to do with the placeholder work item

The first two rules, version created and version updated, could be merged where the update rule detects when the work item is missing and first creates it before proceeding.

Anthony Pugliese

@Bill Sheboy
thanks for the help, looks like ill have to be content with multiple emails going out for the short term as creating a global field is not going to be possible

was hoping to do this all directly through the release function, but looks like its limited and i am probably doing as much as possible

just spitballing.....is there anyway to use a for each branch, to set a variable? and every variable created compares what is to be created and sets the variable as unique? Variable+1, Variable +2? and max it out to 5 variables (being i dont think ill need more than 5 approvers at any one time) and therefore i can always hardcode the variables to the single email comms

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-cloud

release

jira-service-management-cloud

jira-service-management