ISC Workflow jsonpath array becomes single object

Hi all, :slight_smile:

I noticed a bug in workflows. To show this bug, let’s take a simplified use case where we want workflows to send an email that displays the native identity of all disabled accounts of a specific source.

We start with the action Get Accounts and get all accounts from a specific source, then use the Send Email action. In the Send Email action, we use the templating context and define the variable disabledAccounts to be $.getAccounts.accounts[?(@.disabled)].
We then loop over the disabledAccounts in the body of the Send Email using apache velocity:

#if (${disabledAccounts}) The following accounts are disabled: #foreach ( $account in ${disabledAccounts})${account.nativeIdentity}, #end#else No accounts are disabled.#end

This usually works. $.getAccounts.accounts[?(@.disabled)] is a JSONPath expression and SailPoint refers in the documentation to the Goessner implementation of JSONPath.

According to Goessner, this JSONPath expression will return an array of the objects, unless there is no match, in which case it might return false instead of an empty array.

However, the behavior of SailPoint here is different when only one account matches the filtering. It should, according to Goessner, give an array with one object in it, such that we can loop over this array of one object. Now, SailPoint returns the single object instead of the array. As a consequence, if we now loop over the results, it does not iterate over the array of one object and have one iteration where we can describe the account information. Instead, it loops over the attributes of the account.

This is causing issues to the workflow and we would as a workaround, build a special condition check to determine whether the object we iterate over contains accounts or account attributes.

I have contacted SailPoint Support about this (CS0259813) and as a response I hear that this is considered as an enhancement request rather than a bug description.

To me, If SailPoint documentation is saying that IdentityNow is behaving in a specific way, and it doesn’t, then ensuring that the system will behave this way is not an enhancement, but a bugfix, which should receive the correct priority.

Kind regards,
Angelo

2 Likes

Seconded, and think this issue might extend beyond workflows. I experienced it first hand using the REST API calls.

For example, if I call the list-accounts endpoint using PowerShell, being specific to a single identity (Documented here: list-accounts | SailPoint Developer Community). Initially I expected a JSON hashtable (list) returned, I ran into an issue where even though I knew there was an identity with a single account, I wasn’t getting any return. Here’s my first iteration of the important part of the PowerShell function:

$response = Invoke-RestMethod "
https://$($IdentityNowConfiguration.orgName).api.identitynow.com/v3/accounts?filters=identityId%20eq%20`"$($profileID)`""
-Method 'GET' -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"}

return ($response | convertfrom-json -AsHashtable | ConvertTo-Json)

The “convertfrom-json -ashashtable” can’t convert the response if a single object is returned because it’s not returned in a hashtable/list. This caused me to write the function to return whatever the API gives me and then deal with the two potential type returns, which is not ideal. I would also prefer the implementation to match the Goessner standard.

This issue is unfortunately still existing.

1 Like

Have you found any workaround for this? I am facing the same exact issue

Please reach out to your CSM @nileshnikalje , the more people who observe and report this issue, the higher the priority this would hopefully get by SailPoint to fix this directly, removing the need for everyone to build workarounds.

Hi @SidharthDhev, if filtering results in one object and due to this issue it returns the object itself instead of an array of one object. Then how can you fetch the length of it?
Aren’t you then calling the length method of the object itself rather than the length of the array?

@angelo_mekenkamp

Apologies the query is misunderstood with a similar bug .