Workflow or Process for Adding users to Different Access Profile after Revoke Access

Hi Everyone,

Looking for suggestions on use case

If User is Removed from Access Profile A, immediately user should be granted Access Profile B, appreciate your suggestions

Thanks,

Mahesh

For revoking access, a workflow can be configured using the trigger ‘Provisioning Completed,’ applying filters for the operation type as ‘Modify,’ the specific access profile name, and a provisioning result of ‘Committed.’ After this step, ‘Manage Access’ can be used to assign another access profile. Are the access profiles fixed always?

You can follow Priya’s approach that seems more straight forward for the usecase, But lets say Just in case, you are looking for possible other solutions.

  1. If there is a handful of Access profiles you are looking for, then you can simply create a Role. Where you can target the memberOf Attribute of AD and assign the new access.
  2. If you have something like a mapping. I.e if access A is removed add B, if B is removed add C that sort condition. then you can use connector rules. There you have a flexibility of having a key value pair that updates based on that you can assign the access. Now using powershell scripts, you can trigger a external workflow with the information related to new access that needs to be provisioned. Or you can request the new access using the Sailpoint’s “request-access” api.

Here is workflow i created but its failing to add access -

‘{
“name”: “AD Group Transfer”,
“description”: “Testing”,
“created”: “2025-10-30T14:36:54.829556972Z”,
“modified”: “2025-10-30T16:51:44.022263847Z”,
“modifiedBy”: {
“type”: “IDENTITY”,
“id”: “”,
“name”: “Mahesh”
},
“definition”: {
“start”: “Get Identity”,
“steps”: {
“Check New Membership”: {
“actionId”: “sp:compare-strings”,
“choiceList”: [
{
“comparator”: “StringDoesNotContains”,
“nextStep”: “Manage Access”,
“variableA.$”: “$.trigger.changes[0].newValue”,
“variableB”: “CN=PowerBI - Team - Member,OU=Power BI Groups,OU=Resource Groups,OU=Groups,OU=ABC,DC=abc,DC=local”
}
],
“defaultStep”: “End Step - Failure”,
“displayName”: “Check New Membership”,
“type”: “choice”
},
“Compare Strings”: {
“actionId”: “sp:compare-strings”,
“choiceList”: [
{
“comparator”: “StringContains”,
“nextStep”: “Check New Membership”,
“variableA.$”: “$.trigger.changes[0].oldValue”,
“variableB”: “CN=PowerBI - Team - Member,OU=Power BI Groups,OU=Resource Groups,OU=Groups,OU=ABC,DC=abc,DC=local”
}
],
“defaultStep”: “End Step - Failure”,
“displayName”: “Check Old Membership”,
“type”: “choice”
},
“End Step - Failure”: {
“actionId”: “sp:operator-failure”,
“displayName”: “Failure”,
“failureDetails”: “User not eligible for group transfer”,
“failureName”: “Failure”,
“type”: “failure”
},
“End Step - Success”: {
“actionId”: “sp:operator-success”,
“displayName”: “Success”,
“type”: “success”
},
“Get Identity”: {
“actionId”: “sp:get-identity”,
“attributes”: {
“id.$”: “$.trigger.identity.id”
},
“displayName”: “Get Identity”,
“nextStep”: “Compare Strings”,
“type”: “action”,
“versionNumber”: 2
},
“Manage Access”: {
“actionId”: “sp:access:manage”,
“attributes”: {
“addIdentities.$”: “$.trigger.identity.id”,
“comments”: “User removed from Member group, granting Viewer access”,
“requestType”: “GRANT_ACCESS”,
“requestedItems”: {
“accessItems”: [
{
“id”: “12345”,
“type”: “ENTITLEMENT”
}
]
}
},
“displayName”: “Grant Viewer Access”,
“nextStep”: “End Step - Success”,
“type”: “action”,
“versionNumber”: 1
}
}
},
“enabled”: false,
“executionCount”: 0,
“failureCount”: 0,
“creator”: {
“type”: “IDENTITY”,
“id”: “”,
“name”: “Mahesh”
},
“owner”: {
“type”: “IDENTITY”,
“id”: “”,
“name”: “Mahesh”
},
“trigger”: {
“type”: “EVENT”,
“attributes”: {
“filter.$”: “$[?(@.status == “PASSED” && @.interface == “AccountAttributeUpdate” && @.sourceName == “ABC AD”)]”,
“id”: “idn:identity-attributes-changed”
}
}
}’

I found solution, adding Get Access Step before Manage Access solved Provisioning Failure issue.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.