Retrieve the Access Profile name from a Provisioning Completed trigger Workflow

SailPoint Human Fabric (SHF) SHF Discussion and Questions
, ,
1

Hello,

I’m currently working on an Identity Security Cloud workflow that sends an email when one of a specific group of Access Profiles is requested through the Request Center.

For example, the Access Profiles I want to monitor follow this naming convention:

  • GROUP1 - ACCESS PROFILE 1
  • GROUP1 - ACCESS PROFILE 2
  • GROUP1 - ACCESS PROFILE 3
  • …
  • GROUP1 - ACCESS PROFILE 15

I am using the Provisioning Completed trigger.

The goal is to retrieve the Access Profile that was actually provisioned so that I can:

  1. Check whether it starts with to GROUP1 -
  2. Include the exact Access Profile name in the email sent by the workflow.

However, I’m having an issue with the Access Profile value returned by the trigger.

Instead of getting something like:

GROUP1 - ACCESS PROFILE 1

I receive a value similar to:

GROUP1 - ACCESS PROFILE 1 [Access Profile 2839302]

Because of the additional [Access Profile XXXXX] value appended to the name, I cannot directly use this value in a Get Access Profile step, as it does not match the actual Access Profile name.

Has anyone encountered this behavior with the Provisioning Completed trigger?

What would be the recommended way to retrieve the actual Access Profile name (or preferably its ID) that caused the provisioning operation?

I ultimately need to identify exactly which Access Profile was provisioned and include its name in the notification email.

Many thanks for your help!

2

Hi @DivyaL_7 ,this is a known ISC behavior — the [Access Profile XXXXXX] suffix is appended automatically by the trigger. You can clean it up directly in the workflow without any extra API calls!

Step 1: Define Variable — capture raw name from trigger payload:

{{$.accountRequests[0].attributeRequests[0].value}}

Step 2: Define Variable — strip the suffix using replaceAll:

  • Pattern → \s*\[Access Profile\s*\d+\]
  • Replace with → (empty)

This turns GROUP1 - ACCESS PROFILE 1 [Access Profile 2839302] into GROUP1 - ACCESS PROFILE 1 :white_check_mark:

The following example is for Role you can implemen the same for AP too

{
  "name": "rolename",
  "description": "",
  "transforms": [
    {
      "id": "sp:transform:replace:string",
      "input": {
        "pattern": "\\[cloudRole-\\d+\\]",
        "replacement": ""
      }
    },
    {
      "id": "sp:transform:trim:string",
      "input": {
        "postfix": true,
        "prefix": false
      }
    }
  ],
  "variableA": "{{$.loop.loopInput.attributeRequests[0].attributeValue}}"
}

To be precise

{
  "name": "Remove Access Profile ID",
  "transforms": [
    {
      "id": "sp:transform:replace:string",
      "input": {
        "pattern": "\\s*\\[Access Profile\\s+\\d+\\]",
        "replacement": ""
      }
    },
    {
      "id": "sp:transform:trim:string",
      "input": {
        "prefix": true,
        "postfix": true
      }
    }
  ],
  "variableA": "{{$.loop.loopInput.attributeRequests[0].attributeValue}}"
}
3

An excellent piece of advice. A simpler version of the above:

{
  "name": "role",
  "description": "",
  "transforms": [
    {
      "id": "sp:transform:replace:string",
      "input": {
        "pattern": "[.*",
        "replacement": ""
      }
    }
  ],
  "variableA.$": "$.loop.loopInput"
}

Note: If using the GUI, you HAVE to initially add a replacement value, but you can then open up the ‘advanced editor’ and remove it from there

4

Thanks for sharing this! One suggestion based on my implementation experience: I faced an issue because there was a space before the opening square bracket ([). To avoid this, it would be safer to include \\s* in the regex:

{
  "name": "role",
  "description": "",
  "transforms": [
    {
      "id": "sp:transform:replace:string",
      "input": {
        "pattern": "\\s*\\[.*",
        "replacement": ""
      }
    }
  ],
  "variableA.$": "$.loop.loopInput"
}

{
  "name": "role",
  "description": "",
  "transforms": [
    {
      "id": "sp:transform:replace:string",
      "input": {
        "pattern": "\\[.*",
        "replacement": ""
      }
    },
    {
      "id": "sp:transform:trim:string",
      "input": {
        "prefix": true,
        "postfix": true
      }
    }
  ],
  "variableA.$": "$.loop.loopInput"
}

This removes any whitespace before the bracket along with the bracketed text. Alternatively, you can keep the original pattern and add a Trim String transform afterward to remove any leading or trailing whitespace. Both approaches work, but I encountered issues due to the extra space, so including \\s* makes the transform a bit more robust.