I keep getting "data was not an array" when attempting a custom approver field using lookup table.

[Matthew Chavan]

I have a complex sequential approval process with three levels of approvals and 41 different approvers that is dependent on various user inputs. 

At one stage, the reporter is selecting an approver via radio button (tickets are submitted via form) and custom approver fields are agent selects because not all levels of approval are required for all inputs.

The automation should: (steps not working correctly notated in bold. imgs 1&2)
   -Use the custom field with the radio button to edit the summary.
   -Create a lookup table (users vs userID)
   -Delay for 10 seconds to allow this step to complete
   -Create two variables (lookup against radio select value and provide the userID)
   -Re-fetch issue data
   -Branch and set two custom user fields using the variables
   -Comment the variables on the ticket as a check they are providing the correct data. 
           (Using for troubleshooting)

I keep getting the error "data was not an array" when trying to set the approval fields. 

I have tried:
   -asJSONobject, .asJSON, .asJSONarray in various places in the lookup table, variable,
       and edit issue.
   -update/add/set etc. 
   - "accountID"/"id"/"" prefacing the user ID string
   -adding .accountID, .value, "value" to the edit issue
   -multitudes of other solutions provided through atlassian but haven't been able to resolve.

On another ruleset, I have been able to edit these custom fields when amending one of the fields to {"id":"{{reporter.accountID}}"}, but that's already a smart value.

[Bill Sheboy · Accepted solution]

Hi @Matthew Chavan -- Welcome to the Atlassian Community!

For a question like this, please also post an image of the audit log details showing the rule execution. 

And...it can help to use a screen capture tool or browser addon with scrolling page support for longer rule images.  Please use one of those to post an image of your complete rule in one single file.

Back to your questions, please read all of the following and then update your rule, posting a new image and re-testing...

First for that error, that may indicate your JSON is incorrect for the fields.  If they are multiple-selection user fields, then the array syntax is needed: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Multi-user-picker-custom-field

Next, the Delay() action is not needed after creating the table.  Please remove that.

Are you adding a Re-fetch Issue action because of an earlier edit which requires using those changed fields later in the rule?

For the create of the lookup table, the Values for your user accountId values should not have double-curly brackets around them.  They are not smart values as they are only text.

Next, created variables are plain text, without any structure.  And so you cannot later access an attribute such as accountId, as you try to do for {{ApproverOne.accountId}}  Instead, do that when the value is set.  (See below...)

Finally, when you are looking up the value in the lookup table, I suspect your customfield_10324 is a single-selection, user field.  Is that correct?  If so, please change the variable create to:

{{OpsApprovers.get(issue.customfield_10324.accountId)}}

Kind regards,
Bill

[Matthew Chavan]

Hi Bill!

Thanks for the quick reply. Making the updates, but to answer your questions:

Both custom fields I am trying to change (10298 and 10317) are multi-select user fields. 

The refresh is needed because two users are added as approvers, one as primary and another as backup. The summary is edited to include the name of the primary approver. (e.g. Bob is primary and Paul is backup, Paul can disregard all rmailed approval requests addressed to Bob in the subject line unless he is covering the approvals for Bob. For sure a work around, but it prevents a lot of updates for vacation and sick time. These users are also higher up and not amenable to an OpsGenie solution--I've tried.

Field 10324 is a single select dropdown field that shows on the intake form as radio buttons.

Regarding images--I wish, out IT department is "ambitious" to say the least.

Updated to this and IT WORKED!

{"fields": {
       "customfield_10298": [{"id": "{{ApproverOne}}"}, {"id": "{{ApproverBackup}}"}],
       "customfield_10317": [{"id": "{{ApproverOne}}"                                              }]
}             }

I'm cleaning up a few other things and will provide screenshots.

Thanks so much,

Matthew

[Matthew Chavan]

Context

This is a payment request workflow where a request is submitted and must go through the following status (number of potential users appears in parentheses). 

Expense Review      (40)
Expense Approval   (5)
Expense Approval - Large Amount   (2)
Pending Payment
Payment Input         (3)
Payment Review      (3)
Execution Approval  (5)
Payment Release      (5)
Payment Release - Large Amount   (5)
Send Remittance     (5)
Complete

The steps required and appropriate user to make the approval is dependent on the input. (Complicated because invoices which bypass expense approvals are handled in another system, so an end user can't enter an approver for that step as it's not needed). We also need the ability to send requests back to the beginning and request updates which wipes out all approvals and allows changes to be made to the request.

Automation

Lookup Table

Create Variable

{{issue.customfield_10324}} is a dropdown field and is populated by the reporter submitting a form.

Edit Issue

[Bill Sheboy]

For the going backwards in flow, I am unclear how a rule could do that without first storing the values somewhere, such as in additional custom fields or entity properties.

Looking at what you show for the comment, that is probably adding the users as their accountId values, correct?  If you want them as their displayName values, you could use either an additional lookup table or Re-fetch and then access the values from the updated fields.

Is the remainder of the rule working as expected?

[Matthew Chavan]

Going back - An expense approver can send something back to the reporter. All attachments are deleted and forms unlocked. The request would then either be canceled or move forward through the flow again. 

The summary is stored in an additional custom field so that once approvals are complete it can exist without an approvers name. 

I had added the comment in an attempt to help troubleshoot as I was trying things. If I didn't see the accountID value, I knew that something was wrong in the lookup and fix there first. After I could see the accountID as a comment, I knew everything up to that point was working correctly--but thanks for reminding me to delete that step!

Everything is working as expected and I'm configuring the same for all other approval steps now.