we have run into the following issue the last couple of weeks.
To save money on licenses for some of our companys applications we need to inactivate the account for the user when they no longer have any accesses/entitlements.
We have tried to solve it with rules but the solution get’s so complicated that the code and solution looks really bad. So we have chosen to solve it outside of ISC.
But this is a very simple feature, there already is an attribute on accounts called hasentitlements that could be used for the functionality.
So we have posted an idea for a new feature in the GUI for web-service connectors primarily. We want it to be possible to configure the source to inactivate accounts when all entitlements are removed.
I have given some of the possible solution we can try to achieve this:-
Web Service “Before Operation” Rule (Most Recommended for Automation)
Instead of complex workflow logic, a “Before Provisioning” rule can be used to check if the entitlement being removed is the last one.
Approach: Configure a rule that triggers when a “Remove Entitlement” operation occurs.
Logic: The rule should inspect the provisioning plan, call an API to check the user’s current entitlements on that source, and if the count is zero (or the only remaining entitlement is being removed), change the operation to DISABLE or DELETE.
Benefit: This keeps the logic within the connector configuration rather than complex, external workflows.
Workflow with Loop Operator (No-Code Approach)
If you prefer not to use rules, a Workflow can be used, but it requires careful configuration to handle multiple entitlements.
Approach: Trigger a workflow when an entitlement is removed.
Logic: Use a loop operator to check the count of entitlements. If the count equals 1 before the final removal, trigger the “Disable Account” action on the Web Service connector.
Caution: This can become complex if not designed correctly, as noted in developer forums.
Lifecycle State + Aggregation
You can tie this to your Identity Lifecycle Management.
Approach: When a user moves to a “terminated” or “inactive” state, a workflow ensures all entitlements are removed.
Trigger: Follow this with an aggregation to update ISC, and have a separate workflow or rule that checks if the account has zero entitlements to disable it.
I would go with the Workflow due to the flexibility and overall control for debugging and future improvement.
I first check each application whether they have any default entitlements which should be ignored on the account disabling process. For example, AD have a default global security group “Domain users“ which cannot be deleted/revoked.
Build a Workflow in SailPoint and check identity’s access items count by source and make sure you ignore those default groups in each source. If the count is 0, perform the disable account operation. The Workflow can be a scheduled trigger or a LCS change trigger, and it depends when you want to run this process.
You’re saying and assuming ISC’s view of the accounts’ entitlement association is complete and accurate…and that 0 means 0, and nothing else (such as “I can only see 0, but that’s because of aggregation error”, or “I can only see 0, because that’s my limited scope of the services account privilege”).
For this reason, you may want to really flush out all the assumptions with this happy path requirement before going ahead.
You may also want to consider to implement this control closer to the actual managed / target system. Less assumed dependency.