Workflows: Compare requested access from provisioning completed trigger

We have a requirement to compare the access that user is requesting and after that got provisioned we need to send an email we are using workflow for this and the trigger that we are using is ‘Provisioning Completed’ In the example input trigger that is there in documentation we see ‘attributeValue’ available to check what access that user is requesting

we are using a compare strings to compare the attribute value like
Value1 : $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue==“TEST”)].attributeValue
Value2 : TEST
But it is routing to false path what we observed in the execution logs is at the attributeValue we see it coming as TEST [Access Profile - 12448456] because of which the compare is failing.

Can you please suggest any way we could compare what access the user is requesting.?

Thanks,

Hi, does anyone have any suggestions on the above issue?

Welcome to the developer community Sravani.

I’m not sure why [Access Profile - 12448456] is appearing after your attribute value. Can you please submit a support ticket for this? It looks like a bug, as I would expect only the TEST value to appear.

While you are waiting for support to resolve this, you could try the following JSONpath expression which uses a regular expression to match any attributeValue that starts with TEST.

$.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue

@colin_mckibben Thank you for the suggestion. Yes we have raised the support ticket. I have also tried $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)] But that seems to always route to false.

Oops. I forgot to add the .attributeValue at the end. Try this.

$.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue

Hey @colin_mckibben Yep tried with this also $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue. But not sure that is routing to false path always.
Can you confirm if I’m giving it correct way.?

Value 1 : $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue
Comparison : Equals
Value 2 : TEST

Ah, the issue is with your Value 2. The result of the JSONpath will be TEST [Access Profile - 12448456]. Rather than use the “Compare Strings” operator, try using the “Verify Data Type” operator with the “Exists” Data Type option. That will be a better indicator if the regex succeeded or not.

@colin_mckibben I tried using the ‘Verify Data Type’ operator with the ‘Exists’ data type option but it is still routing to false path.

Value : $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue
Data Type : Exists

image

It succeeded for me. Please double check your trigger input. Are you sure the “TEST [Access Profile]” value exists?

@colin_mckibben We actually have three attribute requests at the same time it looks something as below. Is that why when I’m testing it is routing to false.?

"attributeRequests": [
    {
        "operation": "Add",
        "attributeName": "detectedRoles",
        "attributeValue": "Example [AccessProfile-2642745]"
    },
    {
        "operation": "Add",
        "attributeName": "detectedRoles",
        "attributeValue": "TEST [AccessProfile-65487858]"
    },
    {
        "operation": "Add",
        "attributeName": "detectedRoles",
        "attributeValue": "ABCD [AccessProfile-48579846]"
    }
]

It shouldn’t matter. It will match on the only attribute request that has the “TEST” value. Something I noticed in the example you provided is that the double quotes are strangely formatted.

You use , but the correct form is ". I tried your example and it failed as you said.

Are you pasting this example into the trigger input when testing your workflow? That would explain why it’s failing. Try pasting this example input instead and see if it succeeds.

{
  "trackingNumber": "4b4d982dddff4267ab12f0f1e72b5a6d",
  "action": "IdentityRefresh",
  "requester": {
    "id": "2c91808b6ef1d43e016efba0ce470906",
    "name": "Adam Admin",
    "type": "IDENTITY"
  },
  "recipient": {
    "id": "2c91808b6ef1d43e016efba0ce470909",
    "name": "Ed Engineer",
    "type": "IDENTITY"
  },
  "errors": [
    "General Error",
    "Connector AD Failed"
  ],
  "warnings": [
    "Notification Skipped due to invalid email"
  ],
  "sources": "Corp AD, Corp LDAP, Corp Salesforce",
  "accountRequests": [
    {
      "source": {
        "id": "4e4d982dddff4267ab12f0f1e72b5a6d",
        "name": "Corporate Active Directory",
        "type": "SOURCE"
      },
      "accountId": "CN=Rob.Robertson,ou=csm,ou=sales,dc=helpco,dc=com",
      "accountOperation": "Modify",
      "provisioningResult": "SUCCESS",
      "provisioningTarget": "Corp AD",
      "ticketId": "72619262",
      "attributeRequests": [
        {
          "attributeName": "memberOf",
          "attributeValue": "Example [Access Profile]",
          "operation": "Add"
        },
        {
          "attributeName": "memberOf",
          "attributeValue": "TEST [Access Profile]",
          "operation": "Add"
        },
        {
          "attributeName": "memberOf",
          "attributeValue": "ABCD [AccessProfile]",
          "operation": "Add"
        }
      ]
    }
  ]
}

Hey @colin_mckibben Thank you for the quick reply. The one that I pasted before I guess it may be the pasting issue n=but I’m testing with " only not the other way. But I also did try with the payload that you have given by just changing the names original values. Not sure why it is still routing to false path.

image

can you share your workflow script? Please remove any sensitive data before posting it here.

Script.json (6.5 KB)

I uploaded your script and it succeeded.

This is the input I used when testing:

{
  "trackingNumber": "4b4d982dddff4267ab12f0f1e72b5a6d",
  "sources": "Corp AD, Corp LDAP, Corp Salesforce",
  "action": "IdentityRefresh",
  "errors": ["Connector AD Failed"],
  "warnings": ["Notification Skipped due to invalid email"],
  "recipient": {
    "type": "IDENTITY",
    "id": "2c91808568c529c60168cca6f90c1313",
    "name": "William Wilson"
  },
  "requester": {
    "type": "IDENTITY",
    "id": "2c91808568c529c60168cca6f90c1313",
    "name": "William Wilson"
  },
  "accountRequests": [
    {
      "source": {
        "id": "4e4d982dddff4267ab12f0f1e72b5a6d",
        "type": "SOURCE",
        "name": "Corporate Active Directory"
      },
      "accountId": "CN=Chewy.Bacca,ou=hardcorefigter,ou=wookies,dc=starwars,dc=com",
      "accountOperation": "Modify",
      "provisioningResult": "committed",
      "provisioningTarget": "Sourcename",
      "ticketId": "72619262",
      "attributeRequests": [
        {
          "attributeName": "memberOf",
          "attributeValue": "Example [Access Profile]",
          "operation": "Add"
        },
        {
          "attributeName": "memberOf",
          "attributeValue": "TEST [Access Profile]",
          "operation": "Add"
        },
        {
          "attributeName": "memberOf",
          "attributeValue": "ABCD [AccessProfile]",
          "operation": "Add"
        }
      ]
    }
  ]
}

Hi @colin_mckibben ,

So I tested this way like I have given TEST in the JSONpath expression $.trigger.accountRequests[0].attributeRequests[?(@.attributeValue =~ /TEST.*/)].attributeValue
and I have put TEST in the payload to test the workflow then I see that is routing to true…
image
But when I’m giving the original access profile name I see it is routing to false…
image

Not sure what’s the reason.

Please provide the input that succeeded and the input that failed. Maybe a side-by-side comparison will help us spot the difference.

Hi @colin_mckibben It’s the space issue so the real access profile name that I’m using is having some spaces with in the name. Like for example TEST ACCESS PROFILE. If you test with this name it should false and route to false path. Please check.