We have a requirement to retain a user’s entitlements during a defined grace period following a termination event, rather than removing access immediately. Upon user termination, the account should only be disabled in the target system while the assigned entitlements remain intact throughout the retention period.
We would like to explore the best possible options to support entitlement retention regardless of the provisioning method, whether role-based (RBAC) or request-based. Specifically, for RBAC-managed access, even if the role assignment conditions evaluate to false after the termination event, the associated entitlements should continue to be retained until the retention period expires.
Could you please advise on the recommended approach or available options to achieve this requirement while ensuring consistent access retention across all entitlement assignment mechanisms?
I think the easiest and most out-of-the-box approach is using a dedicated Lifecycle State for that in between grace period.
If you have a termination date attribute from your authoritative source, you can use a DateMath transform to calculate when a user is terminated but has not yet reached the end of the retention period (30 days out). Then, in the identity profile provisioning configuration for that new Lifecycle State, you can select the action to Disable accounts on your target sources rather than removing all access.
This takes care of locking the accounts and retaining request-based access, but to ensure your RBAC entitlements are also retained, you need to also update your role criteria to ensure that you’re taking this new lifecycle state into consideration. Something like this would work: Department == 'Sales' AND (LifecycleState == 'Active' OR LifecycleState == 'Terminated - Grace Period')
If you don’t update the role criteria, ISC will evaluate the user as false upon termination and automatically revoke the role and its entitlements, ignoring the grace period.
With this combined approach, you satisfy all requirements, and you can easily track which users are in this retention period by searching for their cloudLifecycleState.
Let me know if you have any questions on this approach!
A practical approach is to separate account disablement from access revocation.
When a user is terminated, move the identity to an intermediate lifecycle state (for example, Termination – Retention), where the account is immediately disabled but roles and entitlements are retained. Since the account is disabled, the user cannot log in, while their existing access remains intact during the defined retention period.
After the retention period (for example, 30, 60, or 90 days), a scheduled workflow or external scheduler can transition the user to the final Terminated lifecycle state. At that point, RBAC role assignments are removed based on role criteria, and any request-based access can also be revoked through the same workflow.
Assume, you want to remove entitlements after 30 days of termination date.
Introduce an identity attribute(let’s say: assignmentStatus and set the value as: RetainAssignment or RemoveAssignments. You can use application or global rule to set the value based on termination date. if current date is < termination date +30, then RetainAssignment else RemoveAssignments
Update all RBAC bundles by adding a new filter: assignmentStatus = RetainAssignment.
In your leaver, prepare a plan to disable account immediately and schedule a workflow to remove all non-RBAC assignments after 30 days. In the scheduled workflow, you can also have a validation step to make sure user is terminated. Incase user is retained; you can transition to exit step otherwise continue with assignment removal.
For the “disable now, keep everything else” part: Rapid Setup Leaver/Termination processing lets you set each action separately as Immediate or Deferred (N days), per application. Set Disable account = Immediate, Remove entitlements = Deferred, N days. IIQ auto-triggers the removal once the grace period ends.
For your RBAC concern specifically: turn on “Disable deprovisioning of deassigned roles” on the Identity Refresh task. This means when a role’s assignment rule evaluates to false (post-termination) and the role gets deassigned, IIQ leaves the entitlements it granted intact instead of stripping them automatically.
You can use an intermediate lifecycle state for the grace period. When the user is terminated, disable the account immediately but leave the existing roles and entitlements in place.
I don’t know exactly in which case you are using, but you can try this option to achieve it. We have rapid setup configuration for leave, where you can select the remove entitlement later option and give the number of days you want to retain. So, SailPoint will create a Request wakes up on the day and remove it on the day you mentioned.
