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

Automation to add Approvers to a Change without overwriting the original Approvers

John Block

I currently have an automation set so that when a Change Request is submitted, three specific users are set as Approvers. I have been given a requirement that a field be added that list different departments which will then require additional approvers be added whatever specific department is chosen.

The issue I am coming across in my automation is that when I add an If statement for the department, my Then action overwrites the three main approvers I had originally set. The goal will be to add departmental specific approvers to the original three master approvers previously set.

I believe the solution is to use JSON to accomplish this, but I am hitting an error I don't fully understand.

{ "update": { "Approvers": [ {"add": { "id":"myuser'sID" } } ] } }

Returns with the error "Additional fields contains invalid field(s) in "update" or "fields" section: Approvers

I am fairly certain the Approvers field is correct, so I am looking to get a second set of eyes to see what I may need to adjust.

Accepted answers

Bill Sheboy

Hi @John Block

For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!

Until we see those...

That error can be a bit confusing. What is means is the Edit Issue action cannot select a specific field from both the dropdown list and use it in advanced edit with JSON. One of them needs to be removed.

For the scenario you describe, you have a couple of options:

add the default approvers, re-fetch the issue, and then edit again to add the others
use a created variable to build the list of approvers to add, and then make one update with edit issue

Seeing your rule specifics may help to point to one or the other approach.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @John Block

Until we see those...

For the scenario you describe, you have a couple of options:

add the default approvers, re-fetch the issue, and then edit again to add the others
use a created variable to build the list of approvers to add, and then make one update with edit issue

Seeing your rule specifics may help to point to one or the other approach.

Kind regards,
Bill

John Block

Thank you for your suggestions! It currently isn't configured in the most efficient way I'd imagine. Because my department list is lengthy, I have an If statement for each of them which makes it to where I cannot grab the whole automation in a single screenshot.

I start by setting the three main approvers first on the creation of this change type.

From here I have a long list of "if:matches" for each of the department names. I was hoping to use the "Then: Edit issue fields" in order to add approvers to the original three depending on what department is selected.

This is the portion where I am trying the JSON to add another user to the Approvers field without overwriting the initial three that were created in the first screenshot.

I've run the automation with the JSON I listed originally, and it shows successful on the audit. I see that the three original approvers were overwritten by the department's approver.

Here I see the departmental Approver overwrote the three main Approvers.

John Block

Hello @Bill Sheboy

For your suggested actions:

add the default approvers, re-fetch the issue, and then edit again to add the others

I added a fetch data before my { "update": { "Approvers": [ {"add": { "id":"myuser'sID" } } ] } } . My expected behavior for the Update is to add the user to the list of Approvers without overwriting but unfortunately it still sets them as the sole approver.

I'd like to explore your second suggestion.

use a created variable to build the list of approvers to add, and then make one update with JSON

Do you have any links to documentation I can review for this process?

Bill Sheboy

When a rule edits an issue it uses the current data as the starting point.

And so if a rule edits and issue twice in succession, it continues to use the data from the time of rule triggering. Adding a Re-fetch Issue after the first edit reloads the data before proceeding. But your changes have the re-fetch inside the conditional logic and so it is not always happening after the first edit.

Let's try these changes:

trigger: issue created
action: re-fetch issue (This first re-fetch is used because the issue created trigger can fire so quickly some data may not be available to the rule yet. This will slow the rule a bit, reloading the data before proceeding.)
action: edit issue to add the default approvers
action: re-fetch issue (This one re-fetches before trying to add any other approvers.)
some if / else logic to add other approvers...
action: re-fetch issue (This one re-fetches after any edits in the conditional logic.)
the JQL condition on Deployment Date / Time
action: edit issue for the Change type

Regarding adding watchers with JSON, I will update that suggestion to this approach instead to add all the approvers at one time using variables and a lookup table. This assumes there is one-and-only-one Platform selection per issue.

create variable:
- name: varDefaultApprovers
- smart value: a comma-separated values list of the approvers' account ids. For an example with some randomly-generated ids

3de2071209c29ba40fc1096a,3428ee76a935971b31eaf578,

create lookup table: this will be a table of the approvers to add, keyed to your Platform
- name: tblPlatformApprovers
  - row
    - key: API
    - value: f8c5a56c1d5fb48ae474d35d
  - row
    - key: System
    - value: a741f1e3b43270755f908d,85225bfc598bc104eeef7d
  - and other rows...
edit issue:
- select the Approvers field and enter this smart value expression

{{varDefaultApprovers.concat(tblPlatformApprovers.get(issue.Platform.value)).split(",")}}

The way that works is:

starting with the default approver list
build a lookup table of the approvers for each Platform
lookup the Platform watchers for the selected issue value
and concatenate that to the default approvers
now the list may be split and added as approvers

This would replace your current logic for both the default approvers and all of the if / else structure.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud