New Capability: Role Change Propagation

Announcements Product News
, ,
1

This enhancement is brought to you by :aha: Idea AI-I-51

Description

:bangbang: This release introduces a key improvement to ISC Role Management. Now, when access is removed from a Role definition, the corresponding access can also be automatically removed from users assigned to that Role—helping reduce the risk of over-provisioning and keeping access aligned with intended Role design.

With this release, you can now configure ISC to automatically de-provision access from users when it’s removed from the Role they are a member of. Access that is added to a Role definition will continue to be propagated automatically and will operate in the same manner as it does today.

New Capabilities

Role Change Propagation allows you to configure ISC to automatically remove access assignments from users when access rights are removed from their associated Role definitions.

  • A Global Setting is now available to enable/disable the role change propagation feature.
  • The following access changes are now propagated by ISC:
    • Removal of an Entitlement from a Role
    • Removal of an Access Profile from a Role
    • Removal of an entitlement from an Access Profile included in a Role
    • Removal of a Role’s dimension or removing an entitlement or access profile from a Role’s dimension.

Problem

Currently in ISC, removing access rights from a Role doesn’t automatically remove that access from users assigned to it—leading to potential over-provisioning and increased risk.

Solution

Role Change Propagation provides the ability to configure ISC so that when access rights are removed from a Role definition, the corresponding access assignments are removed from users who have the Role assigned.

Note: This is an optional capability. A Global Setting is available to enable/disable the Role Change Propagation feature.

When the following access rights are removed from Role’s definition, the corresponding access assignments will be removed from users who have the Role assigned:

  • Removal of an Entitlement from a Role
  • Removal of an Access Profile from a Role
  • Removal of an entitlement from an Access Profile included in a Role
  • Removal of a Role’s dimension or removing an entitlement or access profile from a Role’s dimension.

Indication that Role Change Propagation is enabled
Indication that Role Change Propagation is enabled1920×969 49.4 KB

Indication that Role Change Propagation is enabled - Apply Changes
Indication that Role Change Propagation is enabled - Apply Changes1920×844 120 KB

Who is affected?

Role Change Propagation is available for all customers.

Action Required

Role Change Propagation is a configurable capability which is disabled by default. Customers who opt to use this capability must enable the Role Propagation system feature in ISC Global Settings.

Important Dates

Last updated on June 30, 2025
The original enablement schedule has been delayed. During the planned sandbox enablement the week of June 23, performance issues were encountered that need to be addressed before rolling out to customer tenants. Apologies for the inconvenience, and an updated schedule will be published here and in the comments once established.

17 Likes
2

Hi @PGookin,

This is a very useful custom setting, thank you for this announcement. Can the admin expect to see the comment “Role propagation enabled” sign immediately after enabling the feature in Global Settings or there is a task that runs in the background to apply such settings to a tenant? Curious to know :slight_smile:

3

This is fantastic news @PGookin, thank you for picking up this important functionality.

We once tried to automate a workaround to mitigate this functionality gap ourselves as part of our role modelling scripts, but trying to build this outside of the internal ISC processes using APIs turned out to be tricky. Some hurdles we noticed:

  1. Creating certifications after updating the roles and access profiles had issues because certifications is relying on SailPoint’s search database, whose information can be 24 hours delayed compared to the real access people have, as per the Search SLA. Therefore, if we removed access from a role, it could take 24 hours before certifications would reflect it.
  2. Certifications do not allow you to remove individual entitlements if such an entitlement happens to be part of an access profile whose entitlements you all have, even though you have never (indirectly) received this access profile. The automatic detection mechanism of ISC is preventing the option of removing loose entitlements in these cases.
  3. Outside of certifications there were limited options to automatically remove loose entitlements, especially if you did not suppose requesting loose entitlements.

Therefore, we concluded this should really be a process built in the SailPoint servers themselves, so we are happy to see it will soon be there.

With this new functionality. I wonder how you have implemented it. Is this functionality dependent on search? If so, it will not properly work as per the SLA if we make multiple changes within 24 hours.

Suppose a role admin adds an entitlement to a role by mistake, and then removes it again within 5 minutes, will all the added access be removed again in a proper manner? Could there be race conditions here?

When can we start testing this functionality in non-production?

When will the deprovisioning start? The moment we call the API to update the access object, only during identity refresh? Or during a different moment?

If I remove an entitlement from a role, but some people still have this entitlement as part of a different role, will deprovisioning be properly prevented for those people? What if we remove the entitlement from both these roles around the same time?

ISC Supports entitlement hierarchy right? How does this new functionality behave with respect to entitlement hierarchy? As example if I have a child entitlement (Belgium read access) as part of one role and a parent entitlement (Europe read access) as part of another role. And suppose that the corresponding source has minimal authorizations, meaning that if you have Belgium, France and Brazil as entitlements and then get Europe, it will get rid of Belgium and France and just show Europe and Brazil. After all, Belgium and France are children of the parent entitlement Europe, so they should not be added at that point. But the moment you lose Europe, will it automatically add back Belgium and France if you have them in different roles?)

Kind regards,
Angelo

3 Likes
4

If a source does not have a call for removing access, will the system try once and fail, or will it initiate multiple retries on the source?

5

Glad to see this coming. I know that access NOT being deprovisioned when it was removed from a role increased our concern for access creep. Will we see Role Insights recommending access to be removed from roles at some point?

6

Gentle reminder @PGookin to respond to the questions raised last last week in response to your announcement.

Also noting that I don’t see any changes so far in any of the tenants I have access to.

With this being such an important change, I want to start testing this thoroughly as soon as possible to make sure it works as expected before it this functionality is being deployed in production.

Kind regards,
Angelo

7

Apologies for the inconvenience, but the original enablement schedule has been delayed. During the planned sandbox enablement the week of June 23, performance issues were encountered that need to be addressed before rolling out to customer tenants. Apologies for the inconvenience, and an updated schedule will be published here and in the comments once established.

8

Hello,

my question about this feature:

What if an entitlement is removed from an accessprofile included in a role by ISC if the entitlement from the specific source is not aggregated anymore? Gets the access in this case removed as well?

Background:
Due to Active Directory Connector does not use ObjectGUID for entitlement ID but instead the DistinguishedName of the AD group (its been an idea for years as well…) it happens often, that the AD group is moved in another AD OU by our IT team, which results in a new entitlement for ISC (so automatically get removed from associated accessprofile).
If this would cause a deprovisioning of the access it would be fatal for us.

Kind regards
Karsten

9

Good question @kkoch, I would expect no provisioning to occur here. If an entitlement is considered deleted by entitlement aggregation, it should be considered deleted from target application, so it would not make sense to remove it from the accounts. That should have been done already automatically on the application side. Nevertheless good to test if this scenario was taken into account by SailPoint.

Thank you for the update @christine_whitlock, good to delay deployment if issues were found. Please let us know once new dates are available for deployment in non-production environments and for deployment in production environments. I have marked this post as watching. New comments trigger notifications, not sure if this also holds when the original post gets updated only.

10

Hey now - I know this is delayed but I have the following questions: How does this work with regard to timing and enable/disabling the feature?

(1) In some cases I WANT this feature on (maybe even in most), but in some cases I don’t; can this be toggled on/off depending on the need? If so, what is the time window to do so?

I would be crappy if say, I had it off, removed an entitlement (with default behavior) - then 2 days later I turn it on and it goes and removes the entitlement from people on target from my action 2 days ago.

11

To add to @SailorKev, it is also crucial that this works immediately. If we call the API to turn off role change propagation, get a 200OK response, we should trust that we can immediately remove an entitlement from a role and hit apply changes without the system still using the previous configuration. Similar to when we turn it on again.

We are noticing this with approval flows. We added an approval flow via API, got a 200OK response, then performed an access request after by API, and then noticed it went through without approval flow.

12

This is a fantastic capability that automates access removal, ensuring users only retain permissions aligned with current role definitions. Its global enable/disable setting offers flexible control, making it easy to tailor to organizational needs. Thank you for the announcement.

13

Has this capability (which should have been by default builtin to avoid compliance issues!) been implemented ?

14

I reached out to our CSM with the request of figuring out when this functionality is estimated to be released (in sandbox and in production), such that we know for which weeks to plan to test this capability. Our CSM also checked with the product team.

As of now this capability has not been deployed yet, and there are no new timelines available for when it will be deployed. I also asked if it is definitely known that the release would appear in the next month or definitely known that it will not (allowing us to plan for other lower priority tasks during the next month), but this is also not known yet.

Let’s hope we will soon get an update on the estimated dates (whether near future or far in the future).