We have an issue where manual work items are not being generated when an employee is terminated and Rapid Setup Leaver doesn’t create work items for applications not defined in the Service Desk application. I wanted to share a finding from our investigation into the RapidSetup Leaver workflow and why certain applications are not generating manual work items when a termination is processed.
Background
When a leaver is processed, the workflow builds a provisioning plan that removes the terminated employee’s access across all applications. For applications integrated with ServiceNow (i.e., connected to the ticket management application), a RITM is created automatically. For applications that are not integrated with ServiceNow but also do not have an automated provisioning connector, we expect a manual work item to be created in IIQ — prompting an administrator to manually remove the access.
The Issue
The leaver workflow is currently sending an `AccountRequest` with operation `Delete` (or `Disable`) for all non-AD applications. For applications that do have a provisioning connector (`supportsProvisioning = true`), this works correctly — the connector executes the deprovisioning automatically. However, for applications without a connector (`supportsProvisioning = false`) and not linked to ServiceNow, the `Delete` operation has no connector to route to. IIQ silently marks these requests as committed without generating a manual work item. This means the access removal for these applications goes untracked.
By contrast, when the same applications are processed through certifications (access reviews), a revocation sends entitlement-level `Remove` operations rather than an account-level `Delete`. The IIQ provisioning engine recognizes these as unmanaged and correctly routes them to a manual work item for administrator action.
Root Cause
The disconnect is that `Delete`/`Disable` operations on applications with no connector are silently dropped by the provisioner. Entitlement-level `Remove` operations on the same applications are flagged as unmanaged and generate manual work items — which is the correct behavior.
Impact if Not Fixed
Access on non-automated, non-ServiceNow applications is not being formally tracked or actioned through IIQ when an employee is terminated. This represents a gap in the leaver process that could result in orphaned accounts going undetected.
I have attached the logs but they are for identities that don’t contain the problematic applications as we don’t see anything being printed in the logger except the fact that they are in the provisioning plan. No error show regarding connector issues or missing reference. The log is attached to give a better picture the end-to-end workflow. We also do notice that sometimes there are instances where RapidSetup Leaver gets kicked off but nothing is being printed in the logs for some identities which impacts troubleshooting (not too sure why). The logger you are looking for in the file is “CIBC_Rapid_Setup_Leaver”.
Hope that helps.
Thanks,
Aly Khan
Additonal notes:
Reproduction Steps :
Go to Debug Page
Search Application | IdentityIQ for ServiceNow Service Desk
Remove an application that should use the Service Desk connector from the file (in our case we used CommStarr to test)
Try to terminate the user. You should see that everything gets put in the provisioning plan and get sent to the provisioning engine. You will see that that all the access should be removed or in pending. But for the application that you removed the refrence of in Step 3, that access will remain on the identity and it should go through the unmanagedPlan steps but no manual work items gets created.
If you try to remove this access through certifications, we see this access gets removed and a manual work item gets generated. I also notice that it says IdentityIQ as the channel and not IdentityIQ for ServiceNow Service Desk in the transaction report.
Outcome/Errors : Outcome is that access is not being removed and no manual work item is being created so business can’t track if this access was successfully removed or not. Through certifications, this works fine. Screenshots of what was shared via the transaction report will be attached along with our RapidSetup Leaver workflow.
Thanks for sharing this. So this issue is specific to RapidSetup Leaver process only, you can still disable/delete the account on such application from UI (Manage Identity > Account page) or batch. Right?
Thanks for the reply. So far we notice that this issue happens only with RapidSetup Leaver. I’m not too sure if this is the same case for the Manage Identity page, I’ll have to test that. Would you want me to try Disable or Delete operation on that page?
Yes, that would confirm if the issue is more widespread than just RapidSetup Leaver. I doubt it to be issue but be sure to check that to confirm. Did you report this to SailPoint through support ticket?
Since leaver is important control in any organization. It has to work for all application managed by SailPoint (connected/disconnected).
I did report this to SailPoint through a ticket but they weren’t much help as they said since the workflow is customized they can only suggest to escalate to expert services or post a discussion on the forums. But I’m a little confused because I was under the impression that the generation of Work Items are part of OOTB functionality but maybe because we are creating the provisioning plan from the workflow they don’t want to comment on it.
I tried to Delete the access from an identity from an application that is not specified in the IdentityIQ for ServiceNow Service Desk Application and should generate a Manual Work Item. I ran an identity refresh and I see the below image:
So I just ran the Perfrom Maintaince task and they completed successfully. I also see the following provisioning transaction. Please see the images below:
Did it generate provisioning transaction of manual type i.e. workitem?
If it did then there is no issue with app config/provisioning engine and this is limited to rapid setup leaver.
Since you mentioned, you are building the plan to disable/delete application accounts for terminated users in workflow, I am assuming you have not configured the rapidsetup leaver behavior for application in your setup (Application > Rapid Setup).
Did you try to configure the rapidsetup leaver at application level? atleast for this CommStar application?
The reason SailPoint cannot help since you are not using the rapidsetup configuration fully in your setup.
Global Settting > Rapid Setup - to configure overall Leaver behavior
Application > Rapid Setup > [Application] - to configure leaver behavior specific to that app like to disable or delete (now vs later)
Also did you confirm that your plan (prepared in our workflow triggered by rapidsetup leaver) really contains the disable/delete operation for CommStar app?
@alybarolia If you LCM is working fine, then you should be seeing a workitem mentioned in the Interactions section of your request pointing to the manual work item. Could you please confirm if it is created or not?
Also, have you tried switching to OOTB RapidSetup Leaver workflow to see how is it working? If it doesn’t work with OOTB then you can revert to Sailpoint with the findings as well.
Even after the perform Maintaince task ran, it still did not generate a work item. Your assumption is correct. We have not enabled anything on the application level regarding RapidSetup. I will try to add some configuration for CommStar. I’m assuming I would need to add some filter for the Disable Account feature, but not too sure what that would be. Any suggestions:
Sadly, I didn’t see an workitem being created after I ran that test above. I have not tried using the OOTB RS Leaver workflow. I will try that as well. Would I just make the Leaver Process point to the OOTB workflow and then try to terminate the identity? Is the OOTB solution to also disable the user’s accounts?
Also, if manual work item is not created for normal access request, possibly something wrong with your LCM workflows aswell. you might want to check that as well.
Thank you for the quick reply. Any thoughts on where I can start troubleshooting? When we try to remove access through certifications, we see on the provisioning report, it send sthe Remove Operation and a manual work item is created. But not through our workflow. Not too sure why.
You don’t have to configure everything under rapidsetup for Comstar. Just configure the leaver part.
If you have used the OOTB leaver workflow and customized it further please ensure you have steps in the workflow to execute immediate or deferred plan based on how you configure the leaver behavior i.e. immediate disable vs disable after n days
Oh I see. I will look into the Leaver options. Once I enable these options (i.e Disable Account/Remove Entitlements) would I need to execute or change anything in my RapidSetup Leaver workflow? Would I need to add a step or call a function?
And as for your other question, I will try to remove the CommStar application from an identity and see if it shows up in the Adminstrator console under Provisioning.
The OOTB leaver workflow has both steps listed below
step to execute immediate plan - in case you are doing disable/delete immediately.
step to execute deferred plan - in case you are doing disable/delete after n number of days.
Please ensure these steps are intact for the OOTB rapidsetup leaver to work. Or as someone already suggested if you can revert to OOTB leaver workflow to test, you can do that as well.
Hi Sanjay, I have enabled CommStarr to use the RapidSetup Leaver options on the application level and I have also modified the workflow so that the workflow uses 2 plans. One plan is all the items that have a catalog item, and the other one is the OOTB solution where we call Calculate Birthright Roles and then Get RapidSetup Plan Builder then finally the leaverPlanBuilder.buildPlan().
I see Work Items are still not being generated but I do see under Work Items with the header as “Manager Approval” and I see 151 Requests. In that request, I see the CommStar application that does not have a catalog item:
What happens when these work items are approved? Ideally they should not need approvals for leaver since the user is terminated as per SoT HR data. Something for you to figure out why approvals are getting generated and disable them.
See what happens after you approve them? do you finally see manual provisioning transaction and work item assigned to app owner for manual disable for ComStarr?
Hi Sanjay , I will hapily try that and get back to you with the results. I just wanted to give a heads up as well that I won’t be in on Thursday or Friday, but I’ll get back to you on Monday if any further updates arise.
