Workflow Trigger Condition error

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi,

We have created a workflow to raise a jira ticket when ever a Access request is approved which is coming from AWS Dev source. So we used the first step as the Trigger “Access Request Decision”. I need to add a filter so that the workflow triggers only for the application AWS Dev and not for all Access requests. I have used the JSONPath

$.trigger.requestedItemsStatus[?(@.clientMetadata.applicationName == ‘AWS Dev’)] which is showing error

Can you please suggest the correct JSONPath for filtering. This is a bit high priority.

sample input given while testing-
{
“accessRequestId”: “4b4d982dddff4267ab12f0f1e72b5a6d”,
“requestedItemsStatus”: [
{
“id”: “2c91808b6ef1d43e016efba0ce470904”,
“name”: “Engineering Access”,
“description”: “Engineering Access”,
“type”: “ACCESS_PROFILE”,
“operation”: “Add”,
“clientMetadata”: {
“applicationName”: “My application”
},
“approvalInfo”: [
{
“approver”: {
“id”: “2c91808b6ef1d43e016efba0ce470910”,
“name”: “Stephen Austin”,
“type”: “IDENTITY”
},
“approverName”: “Stephen.Austin”,
“approvalDecision”: “APPROVED”,
“approvalComment”: " this is an approval comment"
}
],
“comment”: “requester comments”
}
],
“requestedBy”: {
“id”: “2c91808b6ef1d43e016efba0ce470906”,
“name”: “Adam Admin”,
“type”: “IDENTITY”
},
“requestedFor”: {
“id”: “2c91808b6ef1d43e016efba0ce470909”,
“name”: “Ed Engineer”,
“type”: “IDENTITY”
}
}

2

Did you find a solution for this? I am stuck on the same thing.

3

When specifying a trigger filter, the JSONpath is applied directly in our ETS service. This means that you don’t need to specify trigger in the JSONpath. Instead, try this:

$.requestedItemsStatus[?(@.clientMetadata.applicationName == ‘AWS Dev’)]

More information on trigger filtering can be found here: Filtering Events | SailPoint Developer Community

4

Hi, I was doing the same as you suggested Colin but it did not work, after some investigation it seems @.clientMetadata.applicationName is outdated, i.e. the example provided in the "Test workflow is actually incorrect from what is sent, not sure if it has changed recently perhaps. This is a small example what is sent when I look at the workflow log what is actually sent:

"clientMetadata":
{
"requestedAppIcon":"sprite:genapp-default",
"requestedAppId":"xxxxxx",
"requestedAppName":"Jira Testing"
}

i.e. $.requestedItemsStatus[?(@.clientMetadata.requestedAppName == “Jira Testing”)] worked for me.
Perhaps you have the possibility to verify if it has actually changed recently and then I would advise/like that the test workflow is updated to have the correct example format :slight_smile:

5

The contents of clientMetadata is not known by SailPoint, and is empty by default. If you call the submit access request API directly, you have the option to specify any number of key/value pairs in clientMetadata. This information is never processed by IdentityNow, and is only useful for API users who need more context about the access request. In other words, applications that make access requests outside of the request center in IdentityNow can put any information in clientMetadata.

In the case of workflows, it is just using the example payload provided by the ETS service, which puts some dummy data in the clientMetadata field as an example. A live execution of the Access Request Decision trigger will most likely result in different information than what you see in the example. In your case, you received an access request decision event that contains clientMetadata that was included by the “Jira Testing” app when the access request was made.

6

Thanks for the answer, I totally understand that the metadata will be different per request, if you request a role / entitlement it will be different and so forth. However I was refering to the specific case where you request an application (which is the provided example in test workflow for this trigger). As I would presume that it is always called requestedAppName and not applicationName otherwise, how can I write a trigger filter if the input varies for application requests. I just wanted to avoid confusion for me and others in the future :slight_smile:

1 Like