Share all details about your problem, including any error messages you may have received.
Hello everyone, how are you?
Could you please help me? I was reviewing my certifications and noticed a different message: “The item has been revoked, but has not been removed.” This left me confused, because all access is always removed from my target SAP applications and there has never been any leftover access. I checked some users and found that they also have this message, as shown in the images, but only for some profiles within the same application. It does not happen for all profiles — it seems quite random.
I included some images to help you understand: the revocation statuses, the provisioning showing that the access was successfully removed from the application, and the identity page showing that the removal also occurred.
I would like to understand why this message appears for only one profile or, sometimes, even within a single application, only for one specific profile. Could you explain the reason for this message and how I can understand how it was generated for these users?
I observed this issue some time ago, and it was previously resolved after running the Aggregation and Identity Refresh tasks. The problem appears to occur when the EntitlementGroup object is not refreshed correctly.
The certification basically checks, if the revocation happend during the certification window. If it happened, outside of the certification window timeline, it will not get updated, and you will see this message.
Since the access was not removed when certification was active, you are seeing this message.
Hi @Marco-oliveira , Is this a connected application like AD or a disconnected application like delimited, because for the disconnected application it will trigger a manual workitem to remove the particular access from the application.
and if you did not remove the access in the application, it will give you this error in the next certification that the decision was taken as revoked but the access is still present on the user account. This is the SailPoint OOTB functionality as it cannot connect directly to application and check for the accesses present.
This is a connected SAP integration, so no manual work items are generated.
Regarding the period, @Naveen Kumar, I have added an image below showing how my certification period settings are configured. I’ve noticed that the issue always occurs when the system performs the revocation automatically. When the manager selects “Revoke” during the active period, there are no problems. However, when it reaches the automatic closure period and the system revokes the access, the message appears.
Is there any way to make this message disappear or configure the certification so that it is not displayed?
Otherwise, you might verify that all of the work items and/or the aggregation (in the case of manual work items) was completed for the impacted identities.
Hi @naveenkumar3 , recently I observed the same error however I dont see its consistent. Meaning for the same user, there are multiple revocation done as part of a single UAR, and only for few the error appears.
All these accesses are related to AD (connected application), and revocation was completed within revocation period of the certification.
Any thoughts? is this a product bug?
When you say you have seen the message, can you confirm, if the removal was done properly. Confirm it via accessing provisioning console and search with the source certification, and see if all revoke was completed properly.
and from the identity also, can you also check the role/access is removed.
Yes, on both the points.
entitlement was revoked as part of the UAR (verified from user history snapshot)
Also, the revocation activity was completed successfully, which means user is no longer have that entitlement, and I do see a successful provisioning transaction to the Target AD.
can you check if the account aggregation run for the target application?? if not can you run it?? and if certification is still active, can you see if post aggregation, it is still showing.
Yes, the errors are gone after the next AD aggregation on the recent occurrences, however there some old UAR;s where those errors still present (probably driven by UAR completion).
However, what I dont able to draw a conclusion that why it is appearing only for a handful revocation? whereas other similar AD entitlements are revoked without this error.
Point me if there is any existing bug on IIQ?
That’s good to hear, the error went away post aggregation.
I don’t think so it a product bug, there could be scenario, when last time you ran the aggregation these user were missed so that’s why you are seeing the error. and now you ran it went away.
