Help - HTTP Requests failing with $getAccounts references due to escape characters appearing

[Addmanniw (Adam Manning)]

What problem are you observing?

In the last 48 hours, our workflows have begun failing. I do not know if I am going mad, or if a Sailpoint update has introduced a bug.

I am currently getting a user’s account with the ‘getAccounts’ query and then verifying they do indeed have an account in the target source with the verify data type: -

$.getAccounts.accounts[?(@.sourceId== ‘975c77e2e0cb4d888afb6a76295888c4’)].sourceName

So far, so good. I get ‘true’ from that query.

However, I then need to make an API call to get attributes from that account.

I am using the call: -

https://tenenturl.api.identitynow.com/beta/accounts/{{$.getAccounts.accounts[?(@.sourceId== ‘975c77e2e0cb4d888afb6a76295888c4’)].id}}

However, this is failing

In the workflow output, I can see the following is being called: -
“url”: “https://tenenturl.api.identitynow.com/beta/accounts/[\“0338f4ab53b34cb9835922a3c11279f6\”]”,

This workflow started failing during testing, and has previously past the test.

We also have another workflow using the same getAccounts / getAccountAttribute by API call logic, and I can see this is also now failing for the same reason.

I have hardcoded the ‘test account’ ID into the URL as below, and the account get attributes is working correctly: -

https://tenenturl.api.identitynow.com/beta/accounts/0338f4ab53b34cb9835922a3c11279f6

So the question is: -

1. WHY are the escape characters not being removed?
   [" … "]

2. WHAT can I do to remove them if this is intentional?

I have been through the forums and other examples, and the way I am referencing the attribute is absolutely the way being advised, AND this was working until the last 48 hours.

What is the correct behavior?

Bugs are considered issues with a feature that prevent it from behaving as designed. In what way do you believe this feature is not working as designed?

The escape characters should be removed from the variable before being used in the API call.

What product feature is this related to?

Workflows - Identity Security Cloud (IdentityNow)

Please indicate which product and feature you are having issues with. Please include version numbers and any other relevant information.

IDN

What are the steps to reproduce the issue?

See above for recreation steps

Please share a complete and detailed list of steps that others can follow to reproduce this issue. Include links, images, and other supporting information to help us reproduce this. Issues that can be reproduced are more likely to be prioritized.

Do you have any other information about your environment that may help?

This could be software versions, browser versions, special configurations, etc.

[colin_mckibben]

Thank you for reporting this Adam. I have forwarded this to the engineering team as ticket # PLTWRKFLW-6313.

[colin_mckibben]

Other reports of strange behavior since 2-3 days ago:

Workflow HTTP request body parsing error

I have a workflow that uses ETS Dynamic Approval. I use a Sub Workflow that receives the information that is sent to the ETS. My Sub Workflow has a rule that needs to collect the description of the requested access. $.trigger.requestedItems[*].description This ETS was working normally, and about two days ago it started to give this error that I sent you in the chat. For now this error only persists in Sandbox, the same ETS in production is working normally.

Workflows - Pass a list of attribute values from an account to loop as input

I think this is a bug caused during latest updates to workflow (here). Even I have noticed this behavior causing issues in iterating through the output in a workflow that was working until 2-3 days ago where reading an array was giving an output like below: [ "credential_id1", "credential_id2 ] ie with just one set of []

[colin_mckibben]

The issue has been identified and fixed for now. What happened is there was a feature rollout to modify how single item arrays are handled. The JSONpath specification treats single item arrays as arrays, however, there was a design decision early on to remove the array brackets from single item arrays so those items could easily be inserted into inline variables where strings were required. However, this deviation from the JSONpath standard has caused much confusion and workarounds to reintroduce the array brackets to single item arrays.

In order to bring the Workflows implementation back into spec with the JSONpath specification, a change is being worked on to treat single item arrays as arrays. This was rolled out 2 days ago. The team has rolled back this change and will reintroduce it in January with more communication around what the change entails.