# Best Practice for Custom Leaver Workflow Inquiry

**URL:** <https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878>\
**Category:** IIQ Discussion and Questions\
**Tags:** workflows, identityiq\
**Created:** [August 13, 2026, 2:00pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878 "2026-08-13T14:00:28Z")\
**Posts on this page:** 18\
**Page:** 1

<div class="post-metadata">

**Author:** ![kareem\_ramzi](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@kareem\_ramzi](https://developer.sailpoint.com/discuss/u/kareem_ramzi)\
**Post date:** [August 13, 2026, 2:00pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/1 "2026-08-13T14:00:28Z")

</div>

Hello everyone,

I have an inquiry about using LCM Provisioning workflow as a subprocess in a custom leaver workflow (can be run either from a QuickLink or an event trigger).

Currently, two of the steps that the custom leaver workflow has are:

1. A step to remove all roles
2. A step to remove all entitlements and disabling all links (i.e., `AccountRequest` operation is `Disable`, `AttributeRequests` operations are `Remove`, and provisioning policies for each application contain the necessary attributes changes to disable the native account)

Each of these two steps construct a plan, with this plan being executed by a `Provisioner`object.

After each of these steps, we have an extra step which refreshes the identity via the `refreshIdentity` call method. The reason for having two refresh identity steps is that after removal of roles, we can be sure that the entitlements currently residing on that identity are additional entitlements (i.e., not granted by a role) before we head on and remove the identity’s entitlements.

However, as number of applications grow, we fear that the usage of `Provisioner` object in directly executing the plan would degrade performance since we directly execute the plan using this object and not make use of a more efficient process like `LCM Provisioning` as a subprocess.

So, my question is, what is the best practice for implementing such scenario in order to make sure performance is not degraded? Do we:

1. Keep it as it is?
2. Create a large provisioning plan and hand it to the `LCM Provisioning` subprocess?
3. Another better option than the previous two?

If handing it to the `LCM Provisioning` subprocess is better, do we set the `foregroundProvisioning`attribute to `false` or `true`? Since there are steps afterwards that require the provisioning step to be finished. Also, are there any other arguments that need to be set as well?

Thanks in advance.

---

<div class="post-metadata">

**Author:** ![Harikrishna\_06](https://avatars.discourse-cdn.com/v4/letter/h/838e76/32.png) [@Harikrishna\_06](https://developer.sailpoint.com/discuss/u/Harikrishna_06)\
**Post date:** [August 13, 2026, 3:23pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/2 "2026-08-13T15:23:59Z")

</div>

Hi @kareem_ramzi ,

You can configure the new workflow where in first step use call method and select the method name as **buildEventPlan** and pass arguments event, trigger, identityName, and op as disable. **Result variable will be plan**. Later configure **Identity Request Initilaize, Identity Request Provision and Identity Request Finalize subprocess** at last.

Above workflow will automatically disable all the applications.

---

<div class="post-metadata">

**Author:** ![mandarsane](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mandarsane/32/35650_2.png) [@mandarsane](https://developer.sailpoint.com/discuss/u/mandarsane)\
**Post date:** [August 13, 2026, 3:41pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/3 "2026-08-13T15:41:41Z")

</div>

Hi @kareem_ramzi ,

You can have single workflow step to create Provisioning Plan instead of having 2 steps for role and entitlements.

Please check all application and corresponding account provisioning policies which should be removed as part of leaver workflow. If any customizations are needed, provisioning plan should be created accordingly.

---

<div class="post-metadata">

**Author:** ![Shubham7499](https://avatars.discourse-cdn.com/v4/letter/s/71c47a/32.png) [@Shubham7499](https://developer.sailpoint.com/discuss/u/Shubham7499)\
**Post date:** [August 13, 2026, 4:01pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/4 "2026-08-13T16:01:42Z")

</div>

Best practice for implementing a Leaver workflow in SailPoint IdentityIQ is to start with a Rule that creates the provisioning plan based on your specific requirements and configuration. This approach is generally preferred over using the BuildEvent method because it provides greater flexibility and control.

Within the Rule, you can create entitlement removal requests based on the target application. For entitlement removals, ensure that every AttributeRequest includes assignment=“true” so that assigned entitlements are properly deprovisioned during the leaver process.

When creating the leaver provisioning plan, use the appropriate arguments according to your requirements, such as:

deassignEntitlements

noFiltering

noRoleDeprovisioning

After generating the plan, invoke the Compile Provisioning Project step to compile and validate the provisioning actions.

If Identity Request tracking is required, create an Identity Request using the appropriate workflow method and then execute the Identity Request Provision step to process the request. If user notifications are needed, the Identity Request Notify step can also be included.

For provisioning execution, it is recommended to enable background provisioning by setting:

XML

1

foregroundProvisioning=“true”

Show more lines

or configure it according to your processing requirements.

foregroundProvisioning=“true”

Finally, an Identity Refresh step can be added after the Identity Request Provision step to ensure that the identity state, roles, and entitlements are updated correctly.

Overall, this approach provides better control, flexibility, auditability, and consistency for Leaver processing in SailPoint IdentityIQ.

---

<div class="post-metadata">

**Author:** ![mkumariaas](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mkumariaas/32/40387_2.png) [@mkumariaas](https://developer.sailpoint.com/discuss/u/mkumariaas)\
**Post date:** [August 14, 2026, 5:10am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/5 "2026-08-14T05:10:01Z")

</div>

better create your plan and call the lcm provisioning workflow , so it will work like sailpoint native funtionlity and sailpoint will support for any issue.  
FOreground and backgroupnd provisioning, i will go with background true and foreground false. So performance maintaince task will pick as per sailpoint availablity and process , it will not send and try end to end during trigger which may end up with performance.  
in high level  
Do you customization in wrapper workflow and then call lcm provisioning workflow to perform native functionality

---

<div class="post-metadata">

**Author:** ![vikaspawar0303](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/vikaspawar0303/32/34710_2.png) [@vikaspawar0303](https://developer.sailpoint.com/discuss/u/vikaspawar0303)\
**Post date:** [August 14, 2026, 7:16am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/6 "2026-08-14T07:16:56Z")

</div>

> [@kareem\_ramzi](#):
>
> Hello everyone,
> 
> I have an inquiry about using LCM Provisioning workflow as a subprocess in a custom leaver workflow (can be run either from a QuickLink or an event trigger).
> 
> Currently, two of the steps that the custom leaver workflow has are:
> 
> 1. A step to remove all roles
> 2. A step to remove all entitlements and disabling all links (i.e., `AccountRequest` operation is `Disable`, `AttributeRequests` operations are `Remove`, and provisioning policies for each application contain the necessary attributes changes to disable the native account)
> 
> Each of these two steps construct a plan, with this plan being executed by a `Provisioner`object.
> 
> After each of these steps, we have an extra step which refreshes the identity via the `refreshIdentity` call method. The reason for having two refresh identity steps is that after removal of roles, we can be sure that the entitlements currently residing on that identity are additional entitlements (i.e., not granted by a role) before we head on and remove the identity’s entitlements.
> 
> However, as number of applications grow, we fear that the usage of `Provisioner` object in directly executing the plan would degrade performance since we directly execute the plan using this object and not make use of a more efficient process like `LCM Provisioning` as a subprocess.
> 
> So, my question is, what is the best practice for implementing such scenario in order to make sure performance is not degraded? Do we:
> 
> 1. Keep it as it is?
> 2. Create a large provisioning plan and hand it to the `LCM Provisioning` subprocess?
> 3. Another better option than the previous two?
> 
> If handing it to the `LCM Provisioning` subprocess is better, do we set the `foregroundProvisioning`attribute to `false` or `true`? Since there are steps afterwards that require the provisioning step to be finished. Also, are there any other arguments that need to be set as well?
> 
> Thanks in advance.

Remove Roles → Identity Refresh → Build Single Disable/Remove Plan → LCM Provisioning (`foregroundProvisioning=true`) → Post-leaver processing.

This is the approach I’ve typically seen used for large-scale leaver workflows in IIQ environments with many applications.

---

<div class="post-metadata">

**Author:** ![soswain\_resmed](https://avatars.discourse-cdn.com/v4/letter/s/c4cdca/32.png) [@soswain\_resmed](https://developer.sailpoint.com/discuss/u/soswain_resmed)\
**Post date:** [August 14, 2026, 7:54am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/7 "2026-08-14T07:54:56Z")

</div>

Hi @kareem_ramzi

1. Instead of creating two steps one for role removal and second for entitlement removal, you create a method like buildProvisioningPlan to include both roles and entitlements in a single plan  
(Coming to how to identify which entitlement granted by role, you can refer to “granted by role” flag in IdentityEntitlement object of the user)
2. LCM provisoning workflow is good at handling large scale provisioning actitivies, so it would be great to use that and the workflow OOB handles the identity refresh in it’s subprocesses.

Hope this answers your question.

Thanks  
Sam

---

<div class="post-metadata">

**Author:** ![kareem\_ramzi](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@kareem\_ramzi](https://developer.sailpoint.com/discuss/u/kareem_ramzi)\
**Post date:** [August 14, 2026, 9:47am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/8 "2026-08-14T09:47:52Z")

</div>

Thank you all for the helpful responses. I need to emphasize that there are steps after the provisioning step that require the provisioning to be fully done before they’re executed. Also, I got a few concerns:

@Harikrishna_06 Will that assure that the subsequent steps after the provisioning steps will be executed only when provisioning is done?

@mandarsane If I were to create a single step to remove roles and entitlements, how can I differentiate between additional entitlements and entitlements that are granted by roles? What objects do I need to retrieve in my rule in order to add them to the plan: `IdentityEntitlement` or `AttributeAssignment` objects?

@Shubham7499 Same question as the previous one.

@mkumariaas Setting `foregroundProvisioning=false`, will that assure that the subsequent steps will be executed only after provisioning is fully done?

@vikaspawar0303 This workflow can either be called from an event trigger or a QuickLink. So if I set `foregroundProvisioning=true` and the workflow is called from a QuickLink, wouldn’t that hang the browser of the launcher for quite some time given that the plan is large with a lot of applications?

@soswain_resmed Okay so if I use the LCM Provisioning as a subprocess, do I set the `foregroundProvisioning` to true or false? Also, will the subsequent steps only be executed after the provisioning is fully complete or not? I need them to only be executed after the provisioning is fully done with no errors.

---

<div class="post-metadata">

**Author:** ![soswain\_resmed](https://avatars.discourse-cdn.com/v4/letter/s/c4cdca/32.png) [@soswain\_resmed](https://developer.sailpoint.com/discuss/u/soswain_resmed)\
**Post date:** [August 14, 2026, 10:50am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/9 "2026-08-14T10:50:26Z")

</div>

You can keep foregroundProvisioning as true.  
Coming to the subsequent steps, LCM provisioning has OOB error handling to catch any errors pass it on. Before you move to the next step, you can use step transition condition to check whether the LCM workflow executed successfully or not.

Thanks,  
Sam

---

<div class="post-metadata">

**Author:** ![kareem\_ramzi](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@kareem\_ramzi](https://developer.sailpoint.com/discuss/u/kareem_ramzi)\
**Post date:** [August 14, 2026, 11:07am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/10 "2026-08-14T11:07:39Z")

</div>

@soswain_resmed Does the LCM Provisioning subprocess produce an output variable to check if the provisioning was successful or not so I can add it to the step transition condition? If so, what is it called, and what values does it send?

---

<div class="post-metadata">

**Author:** ![soswain\_resmed](https://avatars.discourse-cdn.com/v4/letter/s/c4cdca/32.png) [@soswain\_resmed](https://developer.sailpoint.com/discuss/u/soswain_resmed)\
**Post date:** [August 14, 2026, 11:27am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/11 "2026-08-14T11:27:53Z")

</div>

The project variable is the one which contains the error messages if there are any failure in provisioning. The project is of object Type ProvisioningProject and form it we can get the list of messages and to get any error, the Message.Type should be “Error”.

```java
List<Message> eMsg= project.getErrorMessages() //this will directly get us the error messsages

or

List<String> eMsgList = new ArrayList()

List<Message> msg = project.getMessages() 

for(Message m : msg){

if(m.getType() == Message.type.Error)

eMsgList.add(m.getMessage());

}

```

Thanks,  
Sam

---

<div class="post-metadata">

**Author:** ![kareem\_ramzi](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@kareem\_ramzi](https://developer.sailpoint.com/discuss/u/kareem_ramzi)\
**Post date:** [August 14, 2026, 8:28pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/12 "2026-08-14T20:28:29Z")

</div>

@soswain_resmed Alright so when I call the LCM Provisioning subprocess I would always get an output variable `project` that I can instantly reference in the following step correct? Do I need to add it to my main workflow’s process variables list or anything?

Also, setting `foregroundProvisioning` to `true` and running this workflow from a QuickLink, wouldn’t that lead to hanging the browser for the user that launched the QuickLink?

---

<div class="post-metadata">

**Author:** ![mkumariaas](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/mkumariaas/32/40387_2.png) [@mkumariaas](https://developer.sailpoint.com/discuss/u/mkumariaas)\
**Post date:** [August 15, 2026, 6:31am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/13 "2026-08-15T06:31:14Z")

</div>

@kareem_ramzi yes sailpoint functionlity will not break , its like you have release control and let sailpoint do the thing on backend

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [August 15, 2026, 10:05am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/14 "2026-08-15T10:05:47Z")

</div>

Hello Kareem. Since you are calling LCM Provisioning as a subprocess, the parent waits for it to return before running the next step ([Advanced Workflow Topics](https://documentation.sailpoint.com/identityiq/help/business_processes/advanced_workflow_topics.html)). Sequencing is already guaranteed regardless of `foregroundProvisioning`, so you don’t need `true` for it.

That makes `foregroundProvisioning=false` the better fit for the QuickLink case: it allows the workflow to suspend and resume in a background task thread, so the browser session isn’t held on a long leaver ([reference](https://developer.sailpoint.com/discuss/t/customizing-the-lcm-provisioning-request-access-workflow/83179)), while the subprocess wait still keeps your post-leaver steps in order. `true` only matters if you want it fully synchronous in the session, like testing or an event-trigger run where nothing’s waiting at a browser.

The subprocess returning doesn’t mean every target is finished. Direct read-write connectors apply immediately, but Integration Executors can stay queued and unmanaged requests become work items ([Processing Provisioning Requests](https://documentation.sailpoint.com/identityiq/help/provisioning/process_provisioning.html)).

`project` isn’t passed up automatically. Return it from the subprocess step and declare it in the parent:

```auto
<Return name="project" to="project"/> <!-- on the subprocess step -->
<Variable name="project"/> <!-- in the parent workflow -->

```

Your transition can then read `project.getErrorMessages()` and gate on it, treating a clean result as “no hard errors,” not “every async target done” ([Editing Workflow XML](https://documentation.sailpoint.com/identityiq/help/business_processes/editing_workflow_xml.html)).

---

<div class="post-metadata">

**Author:** ![paul\_hilchey](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/paul_hilchey/32/24080_2.png) [@paul\_hilchey](https://developer.sailpoint.com/discuss/u/paul_hilchey)\
**Post date:** [August 16, 2026, 4:14am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/15 "2026-08-16T04:14:11Z")

</div>

Depending on what you need, the LCM Provisioning workflow may not give you much value.

Using the Provisioner directly to do everything you need may be reasonable.

---

<div class="post-metadata">

**Author:** ![kareem\_ramzi](https://avatars.discourse-cdn.com/v4/letter/k/f05b48/32.png) [@kareem\_ramzi](https://developer.sailpoint.com/discuss/u/kareem_ramzi)\
**Post date:** [August 16, 2026, 11:20am UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/16 "2026-08-16T11:20:38Z")

</div>

@mkumariaas Alright got it, thank you for the information

@punna0001 Thank you for the extensive details, I got the full picture now.

@paul_hilchey We need to submit large provisioning plans. We believe that as applications grow, provisioning plans will get larger and thus the usage of `Provisioner` to execute the plans will be less efficient than using `LCM Provisioning`.

---

<div class="post-metadata">

**Author:** ![manjesh\_kumar](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@manjesh\_kumar](https://developer.sailpoint.com/discuss/u/manjesh_kumar)\
**Post date:** [August 17, 2026, 8:20pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/17 "2026-08-17T20:20:57Z")

</div>

Hi there,

May be you have already found the solution for this but I think you would want to use OOTB workflow ‘Identity Request Provision’ or directly ‘Provision with retries’ as subprocess to your custom leaver workflow. These OOTB workflow are designed to implement such provisioning requirements.  
And if you want to get the feedback on provisioning then you can also add ‘Identity Request Initialize’ workflow in a step to your custom workflow after you have the Provisioning Plan build. the initialize workflow generates the access request which has all provisioning details depending on what you add to the plan in custom workflow.

I feel LCM provisioning workflow is not better choice for custom leave workflow when there are OOTB workflows available.

Hope this all makes sense to you. Thanks.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [October 16, 2026, 8:21pm UTC](https://developer.sailpoint.com/discuss/t/best-practice-for-custom-leaver-workflow-inquiry/218878/18 "2026-10-16T20:21:41Z")

</div>

Closed on October 16, 2026, 8:21pm UTC

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.