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.

[Bill Sheboy · Accepted solution]

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

[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:

1. starting with the default approver list
2. build a lookup table of the approvers  for each Platform
3. lookup the Platform watchers for the selected issue value
4. and concatenate that to the default approvers
5. 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.

[John Block]

I followed your suggestion and updated my automation the include the action: re-fresh issue after it was created, after the 3 default approvers were added, and then after the If / Else logic. The 3 default approvers were still being overwritten by the departmental user in the If / Else logic. I then tried to use the "Copy from Issue" along with the departmental approver but that did not work as well.

I ran through a test of your JSON suggestion by adding the default approvers and creating a lookup table for one of the Departments with the userID.

In my Audit log I receive an error "Error while parsing additional fields. Not valid JSON."

I am using the following to try and edit the approvers field using split you gave an example of.

@Bill Sheboy  Thank you so much for taking the time to review this with me. 

[Bill Sheboy]

My mistake as I repeatedly thought "approvers" and kept typing "watchers"!  I updated my earlier posts to correct them.

I just tried what I suggested and it worked for me to paste that expression into the Approvers field.  

Would you please post an image of the audit log details to show what did not work as expected?

Is your Platform, custom field single or multiple selection?

By the way...to do this with JSON, the iterator would need to include the entire "add" syntax for each account ID value, and then skip the final, trailing comma using ^last:

{
  "update": {
    "Approvers": [ { 
      "add": 
        {{#varDefaultApprovers.concat(tblPlatformApprovers.get(issue.Platform.value)).split(",")}} 
          { "id": "{{.}}" } {{^last}}, {{/}} 
        {{/}}
    } ]
  }
}

[John Block]

Thanks again @Bill Sheboy for your suggestions. I configured a lookup table with a couple of the Platform custom field so I could test. This field is Single Selection.

  

I then pasted the smart value for the concat of the three main approvers with the selected value from the table.

On the test tickets I create, I see the three main approvers but have not seen the Platform approvers getting added to the Approvers. My audit is showing success however.

[Bill Sheboy]

That log shows one of the three users is inactive, and so perhaps that prevents adding the approvers.  Try removing that one.

[John Block]

I confirmed that all three main approvers and the departmental approver are active. I then ran a test by removing one of the main approvers and running again. What looks like is happening is the departmental approver gets added without a comma, so the audit looks like it is combining two User IDs. This would explain the inactive user message on the audit. 

I was unable to see this previously due to there not being enough space to display the full log.

I see now in my original Smart value I missed putting a comma behind the last UserID. By adding that comma it looks to be working. I am going to verify with a few more table values and then mark your answer. You Rock @Bill Sheboy !

[Bill Sheboy]

Well done solving that one!