Showing results for 
Show  only  | Search instead for 
Did you mean: 

Snippet: Prevent self-approval of access request

Snippet: Prevent self-approval of access request

Version: 6.2+


Workflow: Provisioning Approval Subprocess


Some installations require that instead of an individual acting as an approver, a Workgroup is utilized instead. This causes a potential issue, what if the user whom the request was submitted for (the requestee) is a member of the Workgroup assigned as its approver? Potentially you have a situation where someone is approving their own access. Depending on the business requirements, this could be considered very bad.



In the provisioning approval subprocess workflow, it is possible to place a "Validation Script" in the step: "Approval". The result is a red error message (customizable) that gets show to the approver who isn't suppose to be approving. All other members of that workgroup are still able to go in and approve as normal. 






      This validation script will check to make sure whoever is trying to approve the

      WorkItem form is not the Identity for which the access was requested.  We do this by

      getting the "completer" value from the WorkItem, if that is the same as the target identity

      "identityName" then a red alert will be shown to that person when they attempt to approve

      the item and they will not be allowed to continue.  Other members of the workgroup will be

      allowed to complete it.



      import java.util.*;

      import sailpoint.api.ObjectUtil;


      //returns the displayName - so need to get the actual identity

      String completer = item.getCompleter();

      //owner from the WI, checking to make sure it is a workgroup

      Identity wiOwner = item.getOwner();

      if(null != wiOwner){


                //utility call that returns all the members of the workgroup in question

                ObjectUtil obj = new ObjectUtil();

                Iterator members = obj.getWorkgroupMembers(context, wiOwner, null);

                if (null != members){


                          //get the individual identity from the list of wg members

                          Identity identityCube= (Identity)([0]);

                          String identityDisplayName = identityCube.getDisplayName();

                          //does the workgroup identity have the same display name as the completer?


                               //found the displayname of the approver in the wg, get the unique ID

                               String identityCubeName = identityCube.getName();

                               //if unique id of the wg member with matching displayName as "completer" matches

                               //the unique id of the target identity, we have a self approval - throw error


                                    return "Error message that will be displayed on the approval page";







                //Check if the completer is just an id, if the id's displayName is equal to completer ... send auto-approve


                Identity requesteeId = context.getObjectByName(Identity.class, identityName);

                if(null != requesteeId){


                          return "Error message that will be displayed on the approval page";






Labels (1)

Nicely done !

I am trying the same thing to ensure that the requestee and approver are not the same person. I tried adding a validation script in the Provisioning Approval Subprocess and even tried the same thing in the Identity Request Approve workflow but the work item nevertheless gets created even when the requestee and approver are the same users (Basically, requestee is the forwarding user of their manager). AM I missing out somewhere?

In 7.2: whenever the approver (a member of the workgroup) is the launcher of the request, then it seems that the validation script is not evaluated (kind of bypassed).

For the validation script to be taken into account, we had to disabled the launcher auto-approval (add <Variable initializer="true" name="disableLauncherAutoApproval" /> in the provisioning approval subprocess workflow). This is annoying as the launcher auto-approval feature is quite convenient from an end user point of view.

Do you know if your script can still coexist in any way with the launcher auto-approval feature?


Hi Laurent,

I haven't tried this in 7.2, but the question would be, is it possible to have a check, early in the workflow that:

  1. Checks if the launcher is the approver
  2. If the launcher is the approver, and is not in the workgroup - set the workflow variable disableLauncherAutoApproval == false
  3. Otherwise, leave as initialized, true

They key would be getting this step inserted prior to whatever logic is evaluating the 'disableLauncherAuthoApproval' flag.  As mentioned, I haven't actually tried this, but let me know if it works!

Hi Adam,

You are right, implementing the logic you are mentionning at the beginning of the Provisioning Approval Subprocess workflow seems to work!

Just for completeness, I think the final logic is the following:

  • if the lancher is the requestee (self-service):
    • if the requestee is not among the approvers --> enable auto-approval
    • else disable auto-approval
  • else enable auto-approval



Hi @laurent_pages ,

We have a similar requirement and are currently on version 8.3p2. I tried adding "<Variable initializer="true" name="disableLauncherAutoApproval" /> in the provisioning approval subprocess workflow and added the above validation script in the approval step but still the validation script doesn't seem to get executed. Any ideas, what I might be missing here?



Poonam Avkire

@adam_creaney, does this solution work for 8.3 workflows as well?

As suggested in the post, I added this validation script in the approval step of "Provisioning Approval Subprocess" workflow but the script itself is not getting executed for me.


Poonam Avkire

Version history
Revision #:
4 of 4
Last update:
‎Apr 28, 2023 09:47 PM
Updated by: