Rename role does not change technical "name"

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Looking to see if anyone can shed some light on this:

Renaming a role in the ui does not change the underlying “name” (technical name?).

Eg: role name was changed from “Role Sync Privileged Bus1 - Dev“ to “Privileged role-Bus1“.

Workflow trigger (provisioning completed) that uses a filter like

$.accountRequests[?(@.source.id==‘IdentityNow’)].attributeRequests[?(@.attributeValue =~ /Privileged role-.*/)]

will not trigger because the ISC passes the old name “Role Sync Privileged Bus1 - Dev“ to the workflow.

This was brought up a couple of yrs ago ( Role Rename Doesn't Actually Change the Name ) but there was no real solution.

This looks like a major bug because not only is there no way to see/reference the old name, ISC seems to use the old and new names in different functions

2

Hi Mario,

If possible, create a new Role with the new name, and delete the old role.

I understand this may not be practical in many cases.. but it the only way I know to clean up the issue

1 Like
3

This is a known issue with ISC: renaming a role in the UI only changes the display name, not the underlying technical name. The old name persists in workflow filters and other backend functions, even though it’s hidden from the UI (source).

Workaround: Create a new role with the correct name and delete the old one—unfortunately, there’s no direct fix or way to update the technical name. This inconsistency has been flagged previously without resolution.

1 Like
4

Thanks @jrossicare and @RAKGDS

Hopefully this gets fixed. It’s a major issue and I’m surprised that it hasn’t been addressed.

5

Hi @mario_rod

The Provisioning Completed payload only gives you attributeRequests with (attributeName, attributeValue, operation). If the role membership event is still emitting the original role “name” string in attributeValue, any regex keyed on the new label won’t ever fire.

workaround so your workflow stays durable

  1. Stop filtering on the role label. Filter on “Role add” generically, then branch inside the workflow using a stable identifier (role id / metadata), not the display string.
    Example trigger filter (broad but reliable):
    $.accountRequests[?(@.source.id==‘IdentityNow’)].attributeRequests[?(@.attributeName==‘roles’ && @.operation==‘Add’)]

  2. In the workflow, extract the role id if it’s present in the attributeValue (some tenants append ids in brackets), then GET /v3/roles/:id and compare on id or on a metadata key you control (accessModelMetadata).
    That avoids brittle string matching and survives future renames.

If you truly need the “technical name” to change everywhere, the only clean option is what Jason mentioned: create a new role with the desired name, migrate assignments, then delete the old role.

If the “broad trigger + resolve role by id + match on id/metadata” approach works in your tenant, please mark this reply as the solution so others can find it.

6

Hi @amrdodani

Thanks for the response. The workflow needs to trigger only on a specific set of roles from a specific source, eg: “*Org Business Dev01 - Src1“, where “Dev01“ is a specific subset of roles from Entra ID source “Src1“

7

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