Hi All,
Account got removed in the target, there is an entitlement from access request is there, and again the account got created using create account.
During Identity Refresh, the account is trying to create again and again and throwing the error below
Identity Refersh keeps on happening when requesting the access
Identity got the entitlement from the access request and the account in the target system got deleted manually. IDN keeps on processing the account for provisioning. The entitlements that are attached to the account are not showing up in the certification as well. Is it sticky entitlement?
What might be the issue for this specific account?
How are the entitlements requested by the users. Did you bundle them into a role and made the role as requestable?
Is it happening with a particular entitlement or with all of the entitlements of this source?
Is this entitlement belongs to a connected or disconnected source?
Can you provide these details to better understand your use case.
If the entitlement was provisioned either as a part of a role or was directly requested in ISC and is removed from the target system, ISC will identify that the account/entitlement is missing and attempt to reprovision. As you mentioned, these items are sticky.
If you want this account to be deleted permanently, you will need to revoke the role/entitlement from the user.
@kani1 IDN’s entitlements are sticky in nature and you would need to revoke the entitlements through access requests or though certifications to remove the stickiness. If not, IDN would try to re-add the entitlements or even create the account if the account doesn’t exist for the user.
Access profiles are one way to handle this (as they are not sticky) but you will need to create an AP for every entitlement that would need to be requested and whenever a new entitlement is added at the target system. This can become difficult if we are talking about a large number of entitlements in the target system.
You can use a workflow to identify account that are deleted. You need to enable native change detection and use the below trigger in the workflow
And later in the workflow you can use HTTP Operation to identify and remove the entitlement.
Other way is using access profiles instead of entitlements as requestable. If you have the frequest account deletions in the target then access profile approach would be cleanest way to achieve this.
