Approval Flexibility

Approval Flexibility functionality offers a set of capabilities to configure Approval Rules and arrange them in multiple levels (sequential and parallel). This feature enables the use of the Out Of The Box ServiceNow Approval module, which makes configuring emails, reports, and other required ServiceNow customizations easier.

SailPoint Administrators (users with role x_sap_intidn.sapadmin) can enable this functionality and configure it by performing the following steps:

Go to SailPoint IdentityNow for Service Catalog > Setup.
Select the Approval Flow dropdown, and then select Configurable Approvals.

Screenshot

There are two key components in order to configure an approval flow; Approval Rules and Approval Definitions.

Approval Rules

The Approval Rules define who should be assigned as an approver for the Access Request.

To configure Approval Rules, perform the following steps:

Go to SailPoint IdentityNow for Service Catalog > Approval Rules.

Screenshot

Select New. The window to create Approval Rules will appear.

The following table lists each field name and description:

Approval Rules - Table

Field Name	Description
Approval Rule Name	The name of the Approval Rule.
Approval Type	Control field for defining the type of approval for the Access Request. Additional fields are displayed based on the type selected. The following types are supported: ServiceNow User ServiceNow Group ServiceNow Role ServiceNow Manager ServiceNow Script IdentityNow Workflow IdentityNow Governance Group IdentityNow Manager IdentityNowOwner ServiceNow Workflow ServiceNow Flow All approval rules are executed in real time when the request is initiated from ServiceNow to IdentityNow. Validation is not performed during rule definitions. In case of any mismatch, the launched approval flow will reject the approval request.
All Must Sign	De-select the checkbox to allow approval flow to proceed when any one of the retrieved users approves. Select the checkbox to allow approval flow to proceed only when all the retrieved users approve. This option is available only for the following Approval Types: ServiceNow Group ServiceNow Role ServiceNow Script IdentityNow Governance Group
Description	The description of the Approval Rule.

Enter a unique name in the Approval Rule Name field.
Select the Approval Type dropdown to make a selection.
The following lists each Approval Type and description:
- ServiceNow User
  Gives the ability to select a ServiceNow User as the approver for the Access Request.
  Screenshot
- ServiceNow Group
  Gives the ability to select a ServiceNow Group. All ServiceNow Users who are members of this group will be assigned as approvers for the Access Request.
  Leave the All Must Sign checkbox unchecked if any one user from the group can approve the request. Select the checkbox if all users from the group should approve the request.
  Screenshot
- ServiceNow Role
  Gives the ability to select a ServiceNow Role. All ServiceNow Users who are members of this role will be assigned as approvers for the Access Request.
  Leave the All Must Sign checkbox unchecked if any one user in the role can approve the request. Select the checkbox if all users in the role should approve the request.
  Screenshot
- ServiceNow Manager
  The Manger as per ServiceNow for whom the request is being raised would be the assigned approver in this access request.
  Screenshot
- ServiceNow Script
  Assigns all ServiceNow Users returned from the ServiceNow GlideRecord query as approvers for the access request.
  Leave the All Must Sign checkbox unchecked if any one user can approve the request. Select the checkbox if all users should approve the request.
  The scripts receive a parameter currentRecord which is the GlideRecord of the Requested Item (RITM). Dot-walk and access every Variable associated with it. For example:
  Access Name | u_access_name
  Access Id | u_access_id
  Access Type | u_access_type
  Start Date | u_start_date
  End Date | u_end_date
  Requested For | requested_for
  Comments | u_comments
  The expected output from the script should be an array of ServiceNow users sys_ids
  Note
  The ServiceNow admin role is needed to modify the ServiceNow Script Field
  Screenshot
  GlideRecord Examples:
  Example 1
  Copy
  // 1.- Get all users from groups IT Help Desk AND Service Desk /** * Description: Retrieves a list of user sys_ids that are members of the groups "IT Help Desk" AND the group Service Desk. The users should be in BOTH groups to be included in the list. * Returns: @relatedUsers | Array(sys_ids) : The list of user sys_ids that are members of both groups. */ (function executeRule(){ var relatedUsers = []; var groupMemberGr = new GlideRecord('sys_user_grmember'); groupMemberGr.addQuery('group.name', 'IT Help Desk'); groupMemberGr.addQuery('group.name', 'Service Desk'); groupMemberGr.query(); while(groupMemberGr.next()){ relatedUsers.push(groupMemberGr.getValue('user')); } return relatedUsers; })();
  Example 2
  Copy
  // 2.- Get all users that has roles x_sap_intidn.user OR x_sap_intidn.onbehalfof /** * Description: Retrieves a list user sys_ids that have the role x_sap_intidn.user OR the role x_sap_intidn.onbehalfof. * Returns: @userIds | Array(sys_ids) : The list of user sys_ids that have the role x_sap_intidn.user OR the role x_sap_intidn.onbehalfof. */ (function executeRule(){ var userIds = []; var userHasRoleGr = new GlideRecord('sys_user_has_role'); userHasRoleGr.addQuery('role', 'x_sap_intidn.user').addOrCondition('role', 'x_sap_intidn.onbehalfof'); userHasRoleGr.query(); while(userHasRoleGr.next()){ userIds.push(userHasRoleGr.getValue('user')); } return userIds; })();
  Example 3
  Copy
  // 3.-Get all users where manager is Abel Tuter /** * Description: Returns the list of user sys_ids that are managed by Abel Tuter. * Returns: @userIds | Array(sys_ids): the list of user sys_ids that are managed by Abel Tuter. */ (function executeRule(){ var userIds = []; var sysUserGr = new GlideRecord('sys_user'); sysUserGr.addQuery('manager.name', 'Abel Tuter'); sysUserGr.query(); while (sysUserGr.next()) { userIds.push(sysUserGr.getUniqueValue()); } return userIds; })();
  Example 4
  Copy
  //4.- Get all users who are managing Tomcat Servers ( cmdb_ci_app_server_tomcat Managed By field) /** * Description: Returns the list of user sys_ids who are managing Tomcat Servers * Returns: @tomcatManagerUsers | Array(sys_ids) : The list of user sys_ids who are managing Tomcat Servers */ (function executeRule(){ var tomcatManagerUsers = []; var cmdbServerTomcatGr = new GlideRecord('cmdb_ci_app_server_tomcat'); cmdbServerTomcatGr.addEncodedQuery('managed_byISNOTEMPTY'); cmdbServerTomcatGr.query(); while(cmdbServerTomcatGr.next()){ tomcatManagerUsers.push(cmdbServerTomcatGr.getUniqueValue()); } return tomcatManagerUsers; })();
  Additional examples
  Copy
  /* Additional examples... As you already noticed, the previous examples are orienten to a specific information, now, How about bring information dinamically: i.e: I want to get a list of the requests that I opened on the last month. */ (function executeRule(){ var requestsOpenedByMe = []; var scRequestGr = new GlideRecord('sc_request'); scRequestGr.addEncodedQuery('sys_created_onONLast month@javascript:gs.beginningOfLastMonth()@javascript:gs.endOfLastMonth()'); scRequestGr.addEncodedQuery('opened_byDYNAMIC90d1921e5f510100a9ad2572f2b477fe'); //This hardcoded sys_id is a SNOW built-in sys_id that works dinamically: is(dynamic) Me. scRequestGr.addQuery() scRequestGr.query(); while(scRequestGr.next()){ requestsOpenedByMe.push(scRequestGr.getUniqueValue()); } return requestsOpenedByMe; })(); //Another way to accomplish the same scenario without the need of hardcoding the sys_id will be as follows: scRequestGr.addQuery('opened_by', gs.getUserID()); //With the "gs.getUserID()" method, you'll get the sys_id of the current user.
- IdentityNow Workflow
  IdentityNow approval is used to initiate the approvals. The Approval request is received by users in ServiceNow. This approval rule will be initiated by IdentityNow workflow after the access request is sent to IdentityNow.
  Screenshot
  Redirect IdentityNow Approval Notifications
  Redirect the IdentityNow Approval Notifications to ServiceNow https://<servicenowinstance>/sp?id=approvals by modification of the notification template https://{tenant}.identitynow.com/ui/admin#admin:global:emailtmpls:AccessRequestReviewer
  Screenshot
  For more information about the SailPoint IdentityNow email templates, refer to Using Email Templates.
  Notifications can also be customized in ServiceNow. For example, this is the notification that is sent every time an approval is generated:
  Notification Example
  For more information, refer to the ServiceNow documentation for Notifications.
  Note
  The "IdentityNow Workflow" type for Approval Definition cannot be combined with other Approval Rules.
  Important
  Approvals should not be Approved or Rejected from IdentityNow, as doing so will impact the consistency between the two systems when using "Configurable Approvals".
- ServiceNow Workflow
  Gives the ability to configure ServiceNow Workflow that will be executed as part of the approval flow. The aim is to give administrators the full flexibility to configure additional approval logic.
  Screenshot
  The ServiceNow Workflow should be built on the Requested Items table (sc_req_item). This way provides access to the current object and it`s variables.
  There cannot be more than one approval rule of type ServiceNow Workflow on a given order. The ServiceNow Workflow is a very flexible option to build really complex approval logic and also to add some custom activities as part of the overall flow.
  Note
  At the end of the Workflow the SailPoint MLA Current Level (x_sap_intidn_sailpoint_mla_current_level) field of the RITM must be set to ‘approved' or 'rejected’. This will trigger the parent approval process to continue it’s flow.
  For example:
  Screenshot
  The Run Script Activity can also be used with this code snippet:
  Copy
```
current.x_sap_intidn_sailpoint_mla_current_level = 'approved';
```
  ServiceNow Flow
  Gives the ability to configure ServiceNow Flow that will be executed as part of the approval flow. The aim is to give administrators the full flexibility to configure additional approval logic.
  Screenshot
  The ServiceNow Flow has access to the current object and it`s variables.
  There cannot be more than one approval rule of type ServiceNow Flow on a given order. The ServiceNow Flow is a very flexible option to build really complex approval logic and also to add some custom activities as part of the overall flow. The ServiceNow Flow should have the trigger set to Service Catalog if the customer wants to get the sys_id of the RITM from the trigger. Other options should be viable as well, though they would require scripting in the Action input field.
  Screenshot
  Note
  At the end of the Flow, the SailPoint MLA Action must be used. This will signal the parent process whether to consider the request as approved or rejected.
  For Example:
  Screenshot
  SailPoint MLA Action internally sets the field SailPoint MLA Current Level (x_sap_intidn_sailpoint_mla_current_level) to ‘approved’ or ‘rejected’.
  It has two input parameters:
  RITM sys_id: the sys_id of the Requested Item.
  Action: ‘approved’ or 'rejected'. Typically, the output of the Ask For Approval Action should be used.
- IdentityNow Governance Group
  Gives the ability to assign anyone or all members from the selected IdentityNow Governance Group as approvers for the access request. The request to IdentityNow will be made to fetch all members of the group and correlate them with the local ServiceNow users.
  Leave the All Must Sign checkbox unchecked if any one user can approve the request. Select the checkbox if all users should approve the request.
  Screenshot
- IdentityNow Manager
  Gives the ability to assign the configured Manager in IdentityNow of the Requested For User as approver for the access request. The request to IdentityNow will be made to fetch the Manager and correlate it with the local ServiceNow user.
  Screenshot
- IdentityNow Owner
  Gives the ability to assign the configured Access Object Owner in IdentityNow as approver for the access request. The request to IdentityNow will be made to fetch the Owner and correlate it with the local ServiceNow user.
  Screenshot
Enter a Description.
Select Submit.

Approval Definitions

The Approval Definitions are used to map SailPoint's IdentityNow Access Object (Role/ Access Profile/ Entitlement) with Approval Rules.

The implemented approval engine processes the approvals on levels in the following way:

The Approval Rules for the Access Request for a given Access Object are processed sequentially based on their order number. One waits for the other to complete.
- Order 100 is the first level of approval.
- Order 200 is the second level of approval.
- Order 300 is the third level of approval.
If there are multiple Approval Definitions for the same Access Object within the same Order, the Approval Rules will apply in parallel. The engine will wait for their completion before moving on to the next Order level.

The following diagram shows an example of how multiple approval levels can be set going up the approval chain.
Example Diagram
1. The first level of approval (Order 100) is the ServiceNow Manager. One user is assigned as the approver. Once the approver approves the request, the second level of approval begins.
2. The second level of approval (Order 200) defines the three rules in parallel; ServiceNow Role, ServiceNow Group, and ServiceNow User. When all three rules are approved, the third level of approval begins.
3. The third level of approval (Order 300) defines the final approval level; ServiceNow User, and ServiceNow Script.
4. If at any time an approver rejects the request then the process is ended, and the next level of approvers never receive the request.

To configure Approval Definitions, perform the following steps:

Go to SailPoint IdentityNow for Service Catalog > Approval Definitions.

Screenshot

Select New. The window to create Approval Definitions will then appear.

The following table lists each field name and description:

Approval Definitions - Table

Field Name	Description
Access Object Type	The Access Object type as defined in SailPoint IdentityNow. Role Access Profile Entitlement
Access Object Name	The Access Object name as defined in SailPoint IdentityNow. Note Validation is performed during execution and not while editing the record in ServiceNow, therefore, caution needs to be maintained to ensure an exact match to the IdentityNow value.
Description	The description of the Approval Definition.
Order	A number field defining the approval level. The Approval Rules for the Access Request for a given Access Object are processed sequentially based on their order number. One waits for the other to complete. If there are multiple Approval Definitions for the same Access Object with the same Order, the Approval Rules will apply in parallel. The engine will wait for their completion.
Active	Enable or disable the definition.
Approval Rule	The Approval Rule that will be applied.

Note

A mapping record must be created for each and every access object name. An easy way to configure in bulk is to create the records offline and import them using the standard ServiceNow Import Set. For more information, refer to Import Sets.
Additionally, generic definitions can be assigned to each object type to avoid definition for each object. For more information, refer to Generic Approval Definition.
Any object definition if defined will be executed ignoring the generic definition for that object.

Select the Access Object Type from the dropdown and specify an Access Object that is already configured in SailPoint IdentityNow.
Use the copy/paste method to enter the Access Object Name exactly as it is in Sailpoint IdentityNow.
Enter a Description.
Select the Active checkbox to enable the definition. Leave it unchecked to disable the definition.
Enter the Order Levels with integers in increasing order for the desired chain of approval. Suggested 100, 200, 300 and so on, which gives flexibility and readability for future changes.
Select Approval Rule Details and then select an Approval Rule that was previously defined.
Select Submit.

Approvals, Flexibility, Considerations, and Limitations (applicable to versions 3.1.0 and earlier)

The following validation rules apply for the Approval Rules and Definitions:

The Approval Rule Name should be unique.
There can be only one unique combination of Access Object and Approval Rule (for the given type Access Profile/ Role /Entitlement).
For Approval Rules of type IdentityNow Workflow, there cannot be multiple Approval Definitions with different order (for given type Access Profile/ Role /Entitlement).
There cannot be more than 2,000 rules per Access Object (for given type Access Profile/ Role /Entitlement).
There cannot be more than one Approval Rule of type ServiceNow Workflow on a given order.
There cannot be more than one Approval Rule of type ServiceNow Flow on a given order.
A signal to the parent process must be provided for Approval Rules of type ServiceNow Workflow or Flow. Set the SailPoint MLA Current Level at the end of it the field to signal the parent process whether the request should be considered approved or rejected.
For Approval Rules of type ServiceNow Flow, flows should be created in the Global or SailPoint IdentityNow for Service Catalog scopes. Support for any application scope will be added in a future version.
Configuring Auto-Approval and behavior when approver and requester/requested for are the same.
For IdentityNow Owner and IdentityNow Manager types of approval under configurable approval:
- If auto-approval is enabled on the IdentityNow side and the approver and requester/requested for is the same user, then the request will be auto approved with the approval comment “Requester or Requested For is same as Approver, this request has been auto approved as per IdentityNow configuration”.
- If auto-approval is disabled on the IdentityNow side and the approver and requester/requested for is the same user, then the approval will be changed to the approver’s manager. The work note “Approver has been changed to approver's manager as per IdentityNow configuration” will be added on the request. If the approver does not have a manager, then the request will be canceled.
- For all other approval types, the request is cancelled when the requestor and approver are the same user.
  
  Note
  Request cancellation when the "requester/requested for" and "approver" is the same user is not applicable for the ServiceNow Flow and Workflow rules.
In order to improve security, the solution rejects the Access Requests if it is unable to assign the correct user as an approver.

The following Auto-Rejection rules apply (applicable to versions 3.1.0 and earlier):
- The ServiceNow User set in an Approval Rule is inactive or was deleted.
- No manager is assigned to the ServiceNow User.
- No appropriate User exists in ServiceNow in the Approval Rule of type IdentityNow Workflow.
- The assigned approver is the same as the Requestor.
- The assigned approver is the same as the Requested For.
- There are Multiple Approval Definitions with the same order, however, one of them is improper (where it is impossible to identify the approver).
- The Approval Rule of type ServiceNow Group and the All Must Sign checkbox is selected, however, some group members are inactive (if users became inactive before the approval assignment they are not selected for review).
- Approval Rule of type ServiceNow Role and the All Must Sign checkbox is selected, however, some role members are inactive (if users became inactive before the approval assignment they are not selected for review).
- Approval Definitions are not set for Access Object.
- Approval Definitions set for Access Object are inactive.
- No rule is specified in Approval Definition (assigned rule was deleted).
Approvals, Flexibility, Considerations, and Limitations (applicable to versions 3.2.0 and later)

The following validation rules apply for the Approval Rules and Definitions:
- The Approval Rule Name should be unique.
- There can be only one unique combination of Access Object and Approval Rule (for the given type Access Profile/ Role /Entitlement).
- For Approval Rules of type IdentityNow Workflow, there cannot be multiple Approval Definitions with different order (for given type Access Profile/ Role /Entitlement).
- There cannot be more than 2,000 rules per Access Object (for given type Access Profile/ Role /Entitlement).
- There cannot be more than one Approval Rule of type ServiceNow Workflow on a given order.
- There cannot be more than one Approval Rule of type ServiceNow Flow on a given order.
- A signal to the parent process must be provided for Approval Rules of type ServiceNow Workflow or Flow. Set the SailPoint MLA Current Level at the end of it the field to signal the parent process whether the request should be considered approved or rejected.
- For Approval Rules of type ServiceNow Flow, flows should be created in the Global or SailPoint IdentityNow for Service Catalog scopes. Support for any application scope will be added in a future version.
- The default group and auto approval settings are not applicable for rule types ServiceNow Workflow, ServiceNow Flow, and IdentityNow Workflow.
- There is no auto approval and no exclusion for requester/requested for if the request is assigned to the default group.
- Any member of the default group can mark the request as approved or rejected. At least one member must mark it.
- For rule type ServiceNow User, ServiceNow Manager, IdentityNow Manager and IdentityNowOwner:
  - Requests are auto-approved when the approver and requester/requested for are the same.
  - If Auto Approve Enabled is set to Yes
    - The request will be auto approved if theapprover and requester/requested for are the same user.
  - If Auto Approve Enabled is set to False
    - ServiceNow User and ServiceNow Manager: The approval will be reassigned to the ServiceNow manager of the approver if the approver and requester/requested for are the same.
    - IdentityNow Manager and IdentityNow Owner: The approval will be re-assigned to the IdentityNow manager of the approver if the approver and requester/requested for are the same.
- The default Approval Group is SailPoint Access Governance Group. This group is designated to approve requests if no approver has been identified during execution of the approval flexibility rules. Any one group member may mark requests as approved.
  
  Use Cases
  - If the approver is missing for ServiceNow Manager, ServiceNow User, IdentityNow Manager, IdentityNow Owner, ServiceNow Group, ServiceNow Role, IdentityNow Governance Group, or ServiceNow Script:
    - The approval will assign to a default of SailPoint Access Governance Group.
    - If SailPoint Access Governance Group is empty or there are no valid members in it, the requested item will be put in a Closed Incomplete state as Request Cancelled, with the approval being Rejected.
    Note
    - For ServiceNow Workflow, ServiceNow Flow, and IdentityNow Workflow, approvals will not be reassigned to the SailPoint Access Governance Group even if no approver is identified.
    - If a requested item(RITM) is marked as Closed Incomplete at any time during its lifecycle, the approval field will be marked as Rejected even if all approvals are successfully completed, as per ServiceNow's OOTB behavior.

In order to improve security, the solution rejects the Access Requests if it is unable to assign the correct user as an approver.

The following Auto-Rejection rules apply (applicable to versions 3.2.0 and earlier):

No appropriate User exists in ServiceNow in the Approval Rule of type IdentityNow Workflow.
There are Multiple Approval Definitions with the same order, however, one of them is improper (where it is impossible to identify the approver).
Approval Definitions are not set for Access Object.
Approval Definitions set for Access Object are inactive.
No rule is specified in Approval Definition (assigned rule was deleted).
If the approval is reassigned to the default group, and there is no active member found in the group.

Approval History

All current and historical data about the approvers is captured in the standard ServiceNow Approval (sysapproval_approver) table.

Additional guidance for Approval Flexibility Approvals

Known Issue during Approval Flexibility (Multi Level Approval) Implementation.

Customers migrating to Approval Flexibility may face the following kinds of errors. This will be addressed in the upcoming release. ServiceNow admins may take the following action to resolve the issue.

For any further help, they may raise a SET ticket.

Issue: Exception (ConversionError): The undefined value has no properties in business rule; skipping business rule.

This error is observed in the following business rules:

SP_SPNT_SNOW_INT_MLA_Approval_Manager
SP_SPNT_SNOW_INT_MLA_Approval_Manager_IW

- OR -

Resolution 2 - Update scripts.

Detailed Steps:

Open the SP_SPNT_SNOW_INT_MLA_Approval_Manager business rule.
Select the Advanced tab.
Remove the condition from the condition text box.

Screenshot

Update the script contents with:

Copy

(function executeRule(current, previous /*null when async*/ ) {
    if (current.document_id.cat_item.getDisplayValue() === "Sailpoint Access Request - Service Catalog" && current.wf_activity == '0d4af8ee1b2799907816c913604bcb3b') {
        var currExex = '';
        var grItem = new GlideRecord('sc_req_item');
        if (grItem.get('sys_id', current.document_id)) {
            if (!gs.nil(grItem.x_sap_intidn_sailpoint_mla_current_level))
                currExec = global.JSON.parse(grItem.x_sap_intidn_sailpoint_mla_current_level);


            //add checks for Idn workflow skip

            //REJECT    
            if (current.state == 'rejected') {

                var grPendingApps = new GlideRecord('sysapproval_approver');
                grPendingApps.addQuery('document_id', current.document_id);
                grPendingApps.query();
                while (grPendingApps.next()) {

                    if (grPendingApps.state == 'requested') {
                        grPendingApps.state = 'not_required';
                        grPendingApps.update();
                    }
                }


                grItem.x_sap_intidn_sailpoint_mla_current_level = 'rejected';
                grItem.update();
            } else if (current.state == 'approved') {
                for (var i = 0; i < currExec.length; i++) {
                    for (var j = 0; j < currExec[i].appList.length; j++) {

                        if (current.sys_id == currExec[i].appList[j] && currExec[i].allSign == '0') {
                            for (var k = 0; k < currExec[i].appList.length; k++) {

                                var grApp = new GlideRecord('sysapproval_approver');
                                if (grApp.get('sys_id', currExec[i].appList[k])) {
                                    if (grApp.state == 'requested') {
                                        grApp.state = 'not_required';
                                        grApp.update();
                                    }
                                }


                            }
                            currExec[i].appList = '';
                            grItem.x_sap_intidn_sailpoint_mla_current_level = global.JSON.stringify(currExec);
                            grItem.update();
                        } else if (current.sys_id == currExec[i].appList[j] && currExec[i].allSign == '1') {
                            currExec[i].appList.splice(j, 1);
                            grItem.x_sap_intidn_sailpoint_mla_current_level = global.JSON.stringify(currExec);
                            grItem.update();

                        }
                    }
                }
            }
        }



        //validate approval
        var count = 0;
        if (grItem.get('sys_id', current.document_id)) {
            var currExec = global.JSON.parse(grItem.x_sap_intidn_sailpoint_mla_current_level);
            for (var i = 0; i < currExec.length; i++) {
                count += currExec[i].appList.length;
            }


            if (count == 0) {
                grItem.x_sap_intidn_sailpoint_mla_current_level = 'approved';
                grItem.update();
            }
        }



    }
})(current, previous);

Open the SP_SPNT_SNOW_INT_MLA_Approval_Manager_IW business rule.
Select the Advanced tab.
Remove the condition from the condition text box.

Screenshot
Update the script contents with:

Copy

(function executeRule(current, previous /*null when async*/ ) {
    if (current.document_id.cat_item.getDisplayValue() === "Sailpoint Access Request - Service Catalog" && current.wf_activity == '4a2c798f1b631d907816c913604bcb6a') {
        var currExex = '';
        var grItem = new GlideRecord('sc_req_item');
        if (grItem.get('sys_id', current.document_id)) {

            //add checks for Idn workflow skip

            //REJECT    
            if (current.state == 'rejected') {

                var grPendingApps = new GlideRecord('sysapproval_approver');
                grPendingApps.addQuery('document_id', current.document_id);
                grPendingApps.query();
                while (grPendingApps.next()) {

                    if (grPendingApps.state == 'requested') {
                        grPendingApps.state = 'not_required';
                        grPendingApps.update();
                    }
                }

                grItem.x_sap_intidn_sailpoint_mla_current_level = 'rejected';
                grItem.update();
            } else if (current.state == 'approved') {

                var grPendingApps = new GlideRecord('sysapproval_approver');
                grPendingApps.addQuery('document_id', current.document_id);
                grPendingApps.query();
                while (grPendingApps.next()) {

                    if (grPendingApps.state == 'requested') {
                        grPendingApps.state = 'not_required';
                        grPendingApps.update();
                    }
                }
                grItem.x_sap_intidn_sailpoint_mla_current_level = 'approved';
                grItem.update();
            }
        }
    }
})(current, previous);


	You are here: