What problem are you observing?
We observe cases where refreshes are not performing the tasks we noticed a year ago. It seems that scope of regular identity refreshes, (unoptimized) account aggregations, role refreshes (apply changes) and manual identity processing has been limited by SailPoint to the point that besides unnecessary computations, also very desired computations are not occurring, leading to identities having roles, without ISC trying to provision the access belonging to it (creating the account if needed).
I did here from others on this forum and in the idea portal that they originally noticed certain actions occurring during automatic refreshes that does not happen anymore, creating undesired effects.
What is the correct behavior?
If someone has a role, and the role points access to applications that a person does not currently have, SailPoint should be able to detect this on a daily basis, when manual identity processing is being executed, when a role refresh (apply changes button) is manually executed, and when an unoptimized account aggregation is being performed. Then it should trigger a provisioning action to create the account if needed and provision the corresponding access.
What product feature is this related to?
Roles, Provisioning, Identity Refresh, Role Refresh. I believe this mostly falls under the team of @kirby_fitch.
What are the steps to reproduce the issue?
This is one way to get in this state: Have a source that can do direct provisioning (we used the web service connector), but have the features in the source JSON contain only read-only related features. Then have a role pointing to this application and another fully working connection. Then request a role for someone who does not have an account on this read-only application (ensure approval if applicable). Because the source is configured as read-only, instead of direct provisioning, it will create a task instead for the source owner. Then add the features back such that direct provisioning could occur. Then mark the task as completed. Then perform an account aggregation, unoptimized aggregation, identity refresh, apply changes. Notice how the identity has the role, but nothing will result in a provisioning attempt.
The (unoptimized) account aggregation could say “Ahh, we thought an account was created manually and we expected it here, but it is not here to lets run a new provisioning”.
The identity refresh and role refresh could see that this identity has that role, but does not have access to it all and will run a new provisioning attempt.
Another option that might trigger this is to start with a read write application, request the role, wait until an account is created, then delete it from the target application and run account aggregation. Since the person has the role, the account should be recreated. Check if this really occurs.
Do you have any other information about your environment that may help?
This occurs in our production environment
Kind regards,
Angelo