# SailPoint ServiceNow Service Catalog Documentation > ServiceNow Service Catalog Documentation # Documentation # Application Level Configuration The following topics are applicable to: - Widgets-based pages - The Manage\_Access page ## Configuring the Search Results Tab ServiceNow admins can hide, show, and reorder the available tabs in the SailPoint service portal page in the order they prefer. The tabs display and order (Role, Access, Profiles and Entitlements) can be controlled. - To get more information about widget options from v5.2 refer to [SailPoint Widget Library]() - 5.1 and prior the setting remains in setup page. ### To Hide or Show the Search Results Tab for Manage Access 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. > **Screenshot** > > [![Configuring the search result tab v5 2]()]() 1. Go to settings with the label. **List and order of Search results tab. Exact text separated by comma to be used. Refer to documentation for examples** (x\_sap\_intidn.x\_sp\_spnt\_snow\_int.specify\_tab\_order). By default, the value of the property is set to be "Roles, Access Profiles". You can hide or show the respective tabs if you add/remove those values. For example, If you fill out the property only with "Roles", the only displayed tab will be the **Roles** tab, hiding the **Access Profiles** tab as a result. For example, - Filling the property with "Roles" only displays the **Roles** tab. > **Screenshot** > > [![Roles]()]() - Filling the property with “Roles, Access Profiles” displays both tabs for **Roles** and **Access Profiles**. > **Screenshot** > > [![Roles1]()]() ## Configuring Approval Flow As an Admin, you may also be responsible for configuring approval flow for the requests generated via the ServiceNow Service Portal Integration for Identity Security Cloud. The way an approval is processed depends on it's configuration. The following three types of Approval Flow are available: - **None (default option)**: Select this option to use only ServiceNow for raising the request. The request is raised in SailPoint without any approval steps in ServiceNow. Approvals are then dependent on the SailPoint configuration. - **Manager Approval**: Select this option to use only ServiceNow as a manager in ServiceNow. - **Configurable Approvals**: Select this option for native ServiceNow approvals. For more details refer to [Approval Flexibility](<#approval-flexibility>). > **Note** > > - The `approvalsMustBeExternal` flag on SailPoint disables creation of approvals in SailPoint. > - For all approval types except `Identity Security Cloud WorkFlow` it is recommended to set the `approvalsMustBeExternal` flag to `true`. Then, only the admin will be able to raise an access request using the SailPoint UI, therefore protecting the appropriate approval process. > - For the `Identity Security Cloud WorkFlow` approval type it is mandatory to set the `approvalsMustBeExternal` flag to `false`. The ServiceNow Service Catalog integration is dependent on SailPoint for approval details, and this will keep requests from getting auto approved. ### 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: 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 2. Select the **Approval Flow** dropdown, and then select **Configurable Approvals**. > **Screenshot** > > [![Copy of Configuring approvals]()]() 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: 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Approval Rules**. > **Screenshot** > > [![Approval Rules]()]() 1. Select **New**. The window to create Approval Rules will appear. > **Screenshot** > > [![New Button]()]() > **Screenshot** > > [![Field Names]()]() 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 - Identity Security Cloud Workflow - Identity Security Cloud Governance Group - SailPoint Manager - SailPoint Owner - ServiceNow Workflow - ServiceNow Flow All approval rules are executed in real time when the request is initiated from ServiceNow to SailPoint. 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 - Identity Security Cloud Governance Group | > | Description | The description of the Approval Rule. | 2. Enter a unique name in the **Approval Rule Name** field. 3. 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** > > [![Copy of ServiceNow User]()]() - 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** > > [![Copy of ServiceNow Group]()]() - 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** > > [![Copy of ServiceNow Role]()]() - ServiceNow Manager The Manger as per ServiceNow for whom the request is being raised would be the assigned approver in this access request. > **Screenshot** > > [![Copy of ServiceNow Manager]()]() - 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 user sys\_ids. If users are retrieved, they will be continued for approvals/rejections. This must be used with extreme caution so required approvals are not skipped. To bypass the approval, the code must return the string `Skip_Approval`. The suggested code is shown in example 5. > **Note** > > - When an approval is skipped, a log entry will be added in the system log, but no comment will be recorded on the RITM. > - The ServiceNow admin role is needed to modify the **ServiceNow Script** Field > **Screenshot** > > [![Copy of ServiceNow Script]()]() GlideRecord examples: > **Example 1** > > ```javascript > // 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** > > ```javascript > // 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** > > ```javascript > // 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** > > ```javascript > // 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; > > })(); > ``` > **Example 5** > > ```javascript > // 5.-Bypass approval in case 'melinda.carleto' user not found > (function executeRule(currentRecord) { > > var approvers = []; > > var grSysUser = new GlideRecordSecure('sys_user'); > grSysUser.addQuery('user_name', 'melinda.carleto'); > grSysUser.query(); > while (grSysUser.next()) { > approvers.push(grSysUser.getValue('sys_id')); > } > > if (approvers.length == 0) { > return 'Skip_Approval'; > } > return approvers; > > })(currentRecord); > ``` > **Additional Examples** > > ```javascript > /* 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. > ``` 1. Identity Security Cloud Workflow SailPoint approval is used to initiate the approvals. The Approval request is received by users in ServiceNow. This approval rule will be initiated by SailPoint workflow after the access request is sent to SailPoint. > **Screenshot** > > [![Copy of IDN WorkFlow]()]() Redirect SailPoint approval notifications: Redirect the SailPoint Approval Notifications to ServiceNow `https:///sp?id=approvals` by modification of the notification template `https://{tenant}.identitynow.com/ui/admin#admin:global:emailtmpls:AccessRequestReviewer` > **Screenshot** > > [![IDN]()]() For more information about the SailPoint 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: > **Screenshot** > > [![Notification]()]() For more information, refer to the ServiceNow documentation for [Notifications](). > **Note** > > If Auto Approval is enabled in SailPoint, an access request is automatically approved when the requester and the approver are the same identity. This works only with the User Account connection method (previously Authorization Code). It does not work with the Service Account connection method (previously Client Credentials). > **Note** > > The "Identity Security Cloud Workflow" type for Approval Definition cannot be combined with other Approval Rules. > **Important** > > Approvals should not be Approved or Rejected from SailPoint, 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** > > [![SN Workflow]()]() 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** > > [![Example1]()]() > **Screenshot** > > [![Example2]()]() The **Run Script** Activity can also be used with this code snippet: ```javascript 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** > > [![SN Flow]()]() 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 complex approval logic and add 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** > > [![Trigger]()]() > **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** > > [![Example3]()]() SailPoint MLA Action internally sets the **SailPoint MLA Current Level** field (`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. It is a suggested practice to use appropriate error handlers. In the flow designer, select the **Error Handler** toggle to enable it. To cancel requested items, set the fields as shown in the screenshot. Additionally, you can add a comment to help users understand the reason of failure along with suggested next steps. > **Screenshot** > > [![Error Handler]()]() - Identity Security Cloud Governance Group Gives the ability to assign anyone or all members from the selected Identity Security Cloud Governance Group as approvers for the access request. The request to SailPoint 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** > > [![IDN Gov Group]()]() - Identity Security Cloud Manager Gives the ability to assign the configured Manager in SailPoint of the Requested For User as approver for the access request. The request to SailPoint will be made to fetch the Manager and correlate it with the local ServiceNow user. > **Screenshot** > > [![IDN Manager]()]() - Identity Security Cloud Primary Owner Gives the ability to assign the configured Access Object Owner in SailPoint as approver for the access request. The request to SailPoint will be made to fetch the Primary Owner and correlate it with the local ServiceNow user. > **Screenshot** > > [![IDN Owner]()]() - Identity Security Cloud Additional Owners Gives the ability to assign the configured Additional Owners of the requested Access Object as approver for the access request. A request will be made to SailPoint to fetch the Additional Owners and correlate it with the local ServiceNow user. If no valid approver is found, approval will be assigned to the default approval group For example, `SailPoint Access Governance Group`. - Identity Security Cloud All Owners Gives the ability to assign the configured Additional Owners and Primary Owner of the requested Access Object as approver for the access request. A request will be made to SailPoint to fetch the Additional Owners and Primary Owner and correlate it with the local ServiceNow user. If no valid approver is found, approval will be assigned to the default approval group. For example, `SailPoint Access Governance Group`. > **Note** > > The Identity Security Cloud All Owners approval type is mutually exclusive and cannot be combined with either Identity Security Cloud Additional Owners or Identity Security Cloud Primary Owner in an approval definition. - Identity Security Cloud Source Owner Gives the ability to assign the configured Source Owner of the requested Access Object as approver for the access request. This approval type is only applicable for an access object of type `Entitlement` or `Access Profiles`. A request will be made to SailPoint to fetch the Source Owner and correlate it with the local ServiceNow user. If no valid approver is found, approval will be assigned to the default approval group. For example, `SailPoint Access Governance Group`. - Identity Security Cloud App Owner Gives the ability to assign the configured Application Owners of the requested Access Object as approvers for the access request. This approval type is only applicable for an access object of type `Access Profiles`. A request will be made to SailPoint to fetch the Application Owner and correlate it with the local ServiceNow user. If there are multiple applications associated with the Access Profile, all the application owners will be fetched and an approval will be generated for each valid user. Leave the **All Must Sign** checkbox unchecked if any one user from the valid approver’s list can approve the request. Select the checkbox if all valid users should approve the request. If no valid approver is found, approval will be assigned to the default approval group. For example, `SailPoint Access Governance Group`. 6. Enter a **Description**. 7. Example 3 ```javascript // 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 3** > > ````text > ```javascript > // 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 3** > > ````text > ```javascript > // 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 5 > > ```javascript > // 5.- Bypass approval in case 'melinda.carleto' user not found > (function executeRule(currentRecord) { > > var approvers = []; > > var grSysUser = new GlideRecordSecure('sys_user'); > grSysUser.addQuery('user_name', 'melinda.carleto'); > grSysUser.query(); > while (grSysUser.next()) { > approvers.push(grSysUser.getValue('sys_id')); > } > > if (approvers.length == 0) { > return 'Skip_Approval'; > } > return approvers; > > })(currentRecord); > ``` 4. Select **Submit**. #### Approval Definitions The Approval Definitions are used to map SailPoint's 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. 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. > **Screenshot** > > [![Order Approval Definitions]()]() To configure Approval Definitions, perform the following steps: 1. Go to **SailPoint IdentityNow for Service Catalog \> Approval Definitions**. > **Screenshot** > > [![Approval Definitions]()]() 1. Select **New**. The window to create Approval Definitions will then appear. > **Screenshot** > > [![New Button AD]()]() > **Screenshot** > > [![Copy of Approval Rules Details]()]() 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. - Role - Access Profile - Entitlement | > | Access Object Name | The Access Object name as defined in SailPoint. 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 SailPoint 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](<#generic-approval-definition>). > - Any object definition if defined will be executed ignoring the generic definition for that object. 2. Select the **Access Object Type** from the dropdown and specify an Access Object that is already configured in SailPoint. 3. Use the copy/paste method to enter the **Access Object Name** exactly as it is in SailPoint. 4. Enter a **Description**. 5. Select the **Active** checkbox to enable the definition. Leave it unchecked to disable the definition. 6. 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. 7. Select **Approval Rule Details** and then select an **Approval Rule** that was previously defined. 8. 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 SailPoint 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 the SailPoint configuration”. - If auto-approval is disabled on the SailPoint 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 the SailPoint 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 `Identity Security Cloud 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 Identity Security Cloud 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 `Identity Security Cloud 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 `IdentityNow Owner`: - 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 the`approver` 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. - `Identity Security Cloud Manager` and `Identity Security Cloud Owner`: The approval will be re-assigned to the SailPoint 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`, `Identity Security Cloud Manager`, `Identity Security Cloud Owner`, `ServiceNow Group`, `ServiceNow Role`, `Identity Security Cloud 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 `Identity Security Cloud 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. > [!NOTE] > > **Screenshot** > > [![Copy of Approval History]()]() Additional guidance for Approval Flexibility Approvals - [Approvals]() - [Approve with a Process Guide]() - [Set Automatic Approval Rules]() - [Configure Status Pooling Timer](<#configure-status-pooling-timer>) #### 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. > [!NOTE] > > **Screenshot** > > [![Error1]()]() > [!NOTE] > > **Screenshot** > > [![Error2]()]() > [!NOTE] > > **Screenshot** > > [![Error3]()]() This error is observed in the following business rules: - SP\_SPNT\_SNOW\_INT\_MLA\_Approval\_Manager - SP\_SPNT\_SNOW\_INT\_MLA\_Approval\_Manager\_IW Add the following condition to both the business rules. In “When to run” for **Approval for.Task type**, the "is Requested" Item needs to be added. > [!NOTE] > > **Screenshot** > > [![Copy of Filter]()]() Detailed steps: 1. Add the AND Filter Condition under “When to run” 2. Show related Fields, Approval for =\> Task Fields, select Task type. 3. Condition “is” 4. Requested Item 5. Select “Update” 6. OR - Detailed steps: 1. Open the `SP_SPNT_SNOW_INT_MLA_Approval_Manager` business rule. 2. Select the **Advanced** tab. 3. Remove the condition from the condition text box. > **Screenshot** > > [![App1]()]() 1. Update the script contents with: ```javascript (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); ``` 4. Open the `SP_SPNT_SNOW_INT_MLA_Approval_Manager_IW` business rule. 5. Select the **Advanced** tab. 6. Remove the condition from the condition text box. > **Screenshot** > > [![App3]()]() 1. Update the script contents with: ```javascript (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); ``` #### Configure Status Pooling Timer By default, the workflow is configured to pool statuses from SailPoint once every 24 hours. This can be changed as per your business requirement in the workflow. > [!CAUTION] > > Be aware that any change made here might need attention during upgrades. 1. In the ServiceNow instance, open the `SP_SPNT_SNOW_INT_CreateSailpointAccessRequest` workflow. 2. Select the timer activity named **Fetching the status of Access Request**, and set the duration. > **Note** > > ServiceNow attempts 100 times before timing out with an error. 1. Select **Update**, and then publish the workflow. ### Generic Approval Definition Approval flexibility requires a definition for each object to apply the approval rules. Often, organizations apply the same rule for an object type with a few exceptions. This section shows how Admins can create generic definitions that can be applied to all objects of a type. > [!NOTE] > > Any definition for an object, if defined, will be executed ignoring the generic definition for that object. #### How to Set Up Generic Approval Definition 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. To enable Generic Approvals, select **Yes** for the **Generic Approval Definition Enabled (Applicable if Configurable Approvals selected for Approval Flow)** option. > **Screenshot** > > [![Copy of Approvals]()]() 1. Create approval rules to be defined for generic definitions. For more information, refer to [Approval Flexibility](<#approval-flexibility>). 2. It is suggested to add text in the description to easily identify the purpose of these rules. For example, `Generic Rule provided by SailPoint`. 2. Create approval definitions. For more information, refer to [Approval Flexibility](<#approval-flexibility>). Regarding generic definitions, use only the following naming process. Generic approval definitions are recognized only by the exact match of the name. - The generic ROLE definition should have the name SAILPOINT DEFAULT ROLE DEFINITION. - The generic ACCESS PROFILES definition should have the name SAILPOINT DEFAULT ACCESS PROFILE DEFINITION. - The generic ENTITLEMENT definition should have the name SAILPOINT DEFAULT ENTITLEMENT DEFINITION. - Create multiple definitions with the same name for serial and parallel definitions. The **Order** column must be used to define the sequence. > **Screenshot** > > [![Copy of Order]()]() ### Limiting External Access Requests SailPoint users typically request access through the SailPoint UI. Access requests can also be initiated from external systems using the access request REST APIs, which allow approvals to flow from the external system into SailPoint for provisioning without requiring additional approval. Access requests initiated within the ServiceNow Service Portal communicate with SailPoint using the access request APIs. As long as access is requested via the ServiceNow Service Portal, the defined approval process will be followed, and access requests will flow to SailPoint for provisioning. This means that users with access to the SailPoint UI could use it to request access and have their request immediately provisioned, bypassing your external approval process. Preventing users who have access to SailPoint from directly submitting the access request can be accomplished in two ways: 1. Disable the SailPoint access request UI by changing the default setting for the `approvalsMustBeExternal` access request configuration option from `false` to `true`. Use the REST APIs to make the following REST call: ```http PUT /beta/access-request-config ``` And include the following in the body of the request: ```json { "approvalsMustBeExternal": true, }, ``` For more information on the use of this API, refer to [Get Access Request Configuration]() in the Developer Community. > **Important** > > Only users with OrgAdmin can raise requests when the flag `approvalsMustBeExternal` is set to `True`. This option is not suggested when using the request catalog for a wider audience. 2. Create a workflow in SailPoint, that uses the `Access Request Dynamic Approver` event trigger to evaluate the origin of an access request, assign an approver, and/or cancel the request if it did not originate from the ServiceNow Service Catalog connector. Suggested Approach: 1. Create a Workflow in SailPoint 1. Setup an external event trigger in SailPoint, subscribing to trigger named `Access Request Dynamic Approver`. 2. In the workflow, add an Approver Action to reflect the individual that would be assigned an approval task if a request is not assigned from ServiceNow. If applicable, configure the HTTP action to cancel the request. > **Important** > > Do not leave access request via SailPoint accessible to users if approvals are configured in ServiceNow. Otherwise, access will be unguarded and vulnerable to misuse. ## Configuring Custom Questions This functionality provides the ability to collect additional information before raising the requests. Users can provide additional information in a question-and-answer format when submitting access requests through the SailPoint Portal. The collected responses are: - Saved in ServiceNow under the Request Item (RITM) - Sent to SailPoint as metadata when creating the access request ### Questionnaire Rules and Questions 1. In ServiceNow, open **SailPoint Identity Security Cloud** from the App Navigator. 2. Open the **Questionnaire Rules** module, and create a rule for: A specific access object, or A general rule that applies to all access objects of a certain type. Access object name needs to be defined as 'Generic' 3. Add Questions to the Rule. Multiple questions with option “is mandatory” of the following types can be added. - Single-Line Text - Multi-Line Text - Dropdown Selection > **Screenshot** > > [![Generic]()]() #### Rule Mapping to Object The following order is used to find the appropriate rule: 1. Exact match: Access Object Name, Type, and Grant Type 2. Generic name match: Access Object Name = "Generic", with matching Type and Grant Type 3. Fully generic match: Access Object Name = "Generic", Type = "ALL", and matching Grant Type #### Displaying the Questionnaire on the Request Page 1. Enable the instance option. Select **Show Additional Information** to display the questionnaire. > **Note** > > Applicable to the widgets for **Review and Submit** or **Review and Submit 2**. > **Screenshot** > > [![Generic1]()]() ## Configuring Page Headers Perform the following steps to offer guidance and instructions to users through customized page headers: 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. > **Screenshot** > > [![Copy 1 of User Experience Flexibility Header text]()]() 1. To enable the customizable text box, select **Yes** on **Show Header text box** 2. Enter instructional text in the desired fields: **User Header text**, **Add Access Header text**, **Recommendations Header text**, **Remove Access Header text**, and **Review & Submit Header text**. String and HTML formats are accepted. 3. Select **Save**. 4. Go to the **Manage Access** Service Portal page to view the configured headers (light blue text box). If the **Show Header text box** option is selected and no instruction text is supplied, the configured headers will be empty. > **Screenshot** > > [![Copy of Page Header1]()]() > **Screenshot** > > [![Empty text box]()]() ## Configuring the Sunset Date ServiceNow admins have the ability to configure the Sunset (Expiration) Date field in ServiceNow as mandatory or non-mandatory while requesting access. The Global Sunset Date field provides the ability to make changes in all requested line items. > [!NOTE] > > Prior to version 3.0, the Sunset Date field in ServiceNow was non-mandatory. Color legend for the sunset date icon: 1. Red - Mandatory and empty 2. Grey - Non-mandatory and empty 3. Primary Color of the ServiceNow instance - Sunset date field has a date value. ### How to Enable Sunset Date Configuration 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 2. Go to settings with the label, **Is Sunset Date Mandatory for Access Requests?** 1. The default is **No**. Select the option for **Yes** to impose this field as mandatory. > **Screenshot** > > [![Copy of Sunsate date]()]() - Users have the ability to copy the Sunset Date across all line items using the **Global Sunset Date** functionality. - The calendar icon in the top right of the page is the Global Sunset Date field. A change made in this field will reflect the same text to the comment fields of all the line items on the page. > **Screenshot** > > [![Copy of Sunset1]()]() > **Screenshot** > > [![Copy of Sunset2]()]() > **Screenshot** > > [![Copy of Sunset3]()]() > **Note** > > Any changes made to individual line items will be overwritten by making edits in the Global Sunset Date field. ## Configuring Native Search ServiceNow search sources make it easier for users to search data on the portal. SailPoint's search source can be configured to help users in finding SailPoint’s access objects through portal search. For more information on searchable fields, refer to [Searchable Fields - SailPoint Identity Services](). Admins in ServiceNow can configure the `SailPoint Search Source` by performing the following steps. 1. Go to **Service Portal \> Portals** and open the relevant portal record. 2. AI Search in ServiceNow doesn't support external sources. Ensure the **Enable AI Search** checkbox is unchecked, and that the scope has been set correctly. > **Screenshot** > > [![a]()]() 1. Go to the Search Sources list and select **Edit**. 2. Add **SailPoint Requestables** to the **Search Source List** and select **Save**. > **Screenshot** > > [![b]()]() > **Note** > > ServiceNow does not support external sources when the AI search feature is enabled. After completing the above mentioned configuration, users will be able to use the service portal search to look for SailPoint access objects. > **Screenshot** > > [![c]()]() Upon selection of any result from the SailPoint requestable source, the signed in user will be redirected to the page that has been defined in the Native Search field on the setup page. For example, manage\_access. The pages `Manage_Access` and `ISC_Request` have been configured to access the values. If you use a custom page, the target page should include the widget for **ISC Access Object Selection**. > **Screenshot** > > [![d]()]() > **Note** > > Search Source will work only for users that have `x_sap_integration.user` or `admin` access in ServiceNow and a valid identity present in SailPoint. ### Adding Paginated Result Support for the SailPoint Search Source By default, the paginate results option is disabled for the `SailPoint Search Source`, however, ServiceNow admins can enable it. > [!CAUTION] > > Due to the data retrieval method of the `SailPoint Search Source` from the REST API, it is essential to utilize facets in conjunction with pagination when conducting searches. This approach guarantees accurate results. To add paginated support for the `SailPoint Requestables Search Source`, refer to the Knowledge Base search source, [Product Documentation | ServiceNow](), as recommended by ServiceNow. In the data retrieval script, ServiceNow uses undocumented objects like query, queryLocation, etc. Any changes made to these objects either by ServiceNow or any other customization may result in paginated search failure. ### Enable the Paginated Result and Facets for the Search Source Admins in ServiceNow can disable pagination for the `SailPoint Search Source` by performing the following steps: 1. Go to **Service Portal \> Search \> Search Sources** and open the `SailPoint Requestables` search source record. 2. Select the checkbox to enable **Paginate Results**. 3. Copy the following code, and paste it into the `Data Fetch Script`. > **For v3.2 and earlier** > > ```javascript > var queryLocation = queryLocation || 0; > var count = count || 30; > (function(query, queryLocation, count) { > var results = []; > var snAccountAttributeValue = ''; > var identityAttributeName = gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.spnt_identity_attribute', '').trim(); > var snAccountAttribute = gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.servicenow_account_attribute', 'name').trim(); > var userID = gs.getUserName(); > > var grUser = new GlideRecord('sys_user'); > if (grUser.get('user_name', userID)) { > snAccountAttributeValue = grUser.getValue(snAccountAttribute); > } > var authScript = new x_sap_intidn.SP_SPNT_SNOW_INT_Auth(); > var accessToken = authScript.getServiceAccountAccessToken(); > > var cmnObj = new x_sap_intidn.SP_SPNT_SNOW_INT_Common(); > var valid = false; > valid = cmnObj.checkIfValidIdentity(accessToken, identityAttributeName, snAccountAttributeValue); > > if (valid) { > var idn_extractRole_scriptIncludes = new x_sap_intidn.SP_SPNT_SNOW_INT_GetAccessListREST(); > idn_extractRole_scriptIncludes.setAuthScript(authScript); > > var accessObjectType = { > 'Access Profiles': 'ACCESS_PROFILE', > 'Roles': 'ROLE', > 'Entitlements': 'ENTITLEMENT' > }; > > var tabs = gs.getProperty("x_sap_intidn.x_sp_spnt_snow_int.specify_tab_order", ""); > tabs = tabs.trim().split(","); > > if (facets.AOType) { > tabs = tabs.filter(function(objType) { > return objType == facets.AOType; > }); > } > if (global.JSUtil.notNil(data.limit) && !isNaN(data.limit)) > count = data.limit + queryLocation; > var resCount = 0; > > tabs.forEach(function(tab) { > if (accessObjectType[tab]) { > var accessList = idn_extractRole_scriptIncludes.getAccessEntitiesCombined(accessToken, query, accessObjectType[tab], '', '', true, queryLocation, count); > if (accessList.count > 0) { > accessList.items.forEach(function(accessObject) { > results.push({ > 'name': accessObject.name, > 'description': accessObject.description ? accessObject.description : '', > 'type': accessObject.type, > 'query_location': queryLocation + resCount, > 'owner': accessObject.Owner, > 'url': '?id=manage_access&itemId=' + accessObject.id > }); > resCount++; > }); > } > } > }); > } else { > gs.info(userID + ' is not a valid identity in SailPoint'); > } > if (results.length == 0) > return results; > if (results.length < count) { > var lastResult = results.pop(); > lastResult.isLastResult = true; > results.push(lastResult); > } > return results; > })(query, queryLocation, count); > ``` > **For v4.0** > > ```javascript > var queryLocation = queryLocation || 0; > var count = count || 30; > (function(query, queryLocation, count) { > var results = []; > var snAccountAttributeValue = ''; > var identityAttributeName = gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.spnt_identity_attribute', '').trim(); > var snAccountAttribute = gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.servicenow_account_attribute', 'name').trim(); > var userID = gs.getUserName(); > var page_id = gs.getProperty('x_sap_intidn.Native_Search_Redirect_Page_ID','manage_access'); var grUser = new GlideRecord('sys_user'); > if (grUser.get('user_name', userID)) { > snAccountAttributeValue = grUser.getValue(snAccountAttribute); > } > var authScript = new x_sap_intidn.SP_SPNT_SNOW_INT_Auth(); > var accessToken = authScript.getServiceAccountAccessToken(); var cmnObj = new x_sap_intidn.SP_SPNT_SNOW_INT_Common(); > var valid = false; > valid = cmnObj.checkIfValidIdentity(accessToken, identityAttributeName, snAccountAttributeValue); if (valid) { > var idn_extractRole_scriptIncludes = new x_sap_intidn.SP_SPNT_SNOW_INT_GetAccessListREST(); > idn_extractRole_scriptIncludes.setAuthScript(authScript); var accessObjectType = { > 'Access Profiles': 'ACCESS_PROFILE', > 'Roles': 'ROLE', > 'Entitlements': 'ENTITLEMENT' > }; var tabs = gs.getProperty("x_sap_intidn.x_sp_spnt_snow_int.specify_tab_order", ""); > tabs = tabs.trim().split(","); if (facets.AOType) { > tabs = tabs.filter(function(objType) { > return objType == facets.AOType; > }); > } > if (global.JSUtil.notNil(data.limit) && !isNaN(data.limit)) > count = data.limit + queryLocation; > var resCount = 0; tabs.forEach(function(tab) { > if (accessObjectType[tab]) { > var accessList = idn_extractRole_scriptIncludes.getAccessEntitiesCombined(accessToken, query, accessObjectType[tab], '', '', true, queryLocation, count); > if (accessList.count > 0) { > accessList.items.forEach(function(accessObject) { > results.push({ > 'name': accessObject.name, > 'description': accessObject.description ? accessObject.description : '', > 'type': accessObject.type, > 'query_location': queryLocation + resCount, > 'owner': accessObject.Owner, > 'url': '?id='+page_id+'&itemId=' + accessObject.id, > }); > resCount++; > }); > } > } > }); > } else { > gs.info(userID + ' is not a valid identity in SailPoint'); > } > if (results.length == 0) > return results; > if (results.length < count) { > var lastResult = results.pop(); > lastResult.isLastResult = true; > results.push(lastResult); > } > return results; > })(query, queryLocation, count); > ``` 1. Uncomment the code from the `Facet Generation Script` and select **Update**. > **Note** > > Any modifications to the internal ServiceNow object utilized in the data fetch script will cause the paginated search to fail. 1. Select **Update**. ## Assigning Roles to the Portal Integration > [!IMPORTANT] > > As an Administrator, you’ll need to assign the role associated with the application integration to every ServiceNow user who will use the ServiceNow Portal Integration for Identity Security Cloud to request access. To do this as a bulk operation and add this role to all ServiceNow users at once, you can run the following script: ```javascript var gr = new GlideRecord("sys_user"); gr.query(); while(gr.next()) { if (gr.accumulated_roles.toString().indexOf(",x_sap_intidn.user,") == -1) { gr.roles = gr.roles + ", x_sap_intidn.user"; gr.update(); } } ``` You can also modify this script to assign the role to a subset of ServiceNow users to better control their access to the Service Catalog app. For more information, refer to [ServiceNow]() to search their help documents. | Role | Description | | --- | --- | | x\_sap\_intidn.user | Users with this role can access the SailPoint Identity Security Cloud for Service Catalog Integration **Manage Access** page, where they can request access. | | x\_sap\_intidn.sapadmin | Users with this role can access the SailPoint Identity Security Cloud for Service Catalog Integration application, to administer it and configure it for others to use. | | x\_sap\_intidn.onbehalfof | Users with this role can access the SailPoint Identity Security Cloud for Service Catalog integration **Manage Access** page, where they can request access for themselves, or on behalf of another user. | | x\_sap\_intidn.certificationuser | Users with this role can access SailPoint's ISC Certification page. | ## Language Internationalization ### Activating Language Internationalization on the ServiceNow Platform - Users with the ServiceNow admin role can activate language internationalization on the ServiceNow platform. Refer to [Activate a language]() for more information. ### Pre-Translated Messages for English and French - If the English language plugin is active on the ServiceNow platform, the SailPoint Manage Access portal shows UI labels in the English language. > **Screenshot** > > [![English Labels]()]() - If the French language plugin is active on the ServiceNow platform, the SailPoint Manage Access portal shows UI labels in the French language. > **Screenshot** > > [![French]()]() ### Extending Language Internationalization Perform the following steps to extend language internationalization support for other languages. For example, Japanese. 1. Open the `sys_ui_message` table records (keys) by applying the application filter **SailPoint Identity Security Cloud for Service Catalog**. > **Screenshot** > > [![1 1]()]() 1. Search for the **User Details** key and open one of the keys. > **Screenshot** > > [![2 2]()]() > **Screenshot** > > [![3 3]()]() 1. Select the **Insert and Stay** option to create an additional (new) key with the name **User Details**. > **Screenshot** > > [![4 4]()]() 1. In the new **User Details** key, select Japanese as the **Language**, update the **Message** to a Japanese message, and **Save** the new key. > **Screenshot** > > [![5 5]()]() > **Screenshot** > > [![6 6]()]() 1. If the Japanese language plugin is active on the ServiceNow platform, the SailPoint Manage Access portal will show UI labels in the Japanese language. > **Screenshot** > > [![7 7]()]() ## Configuring the Comments ServiceNow admins have the ability to configure the comments field in ServiceNow while requesting access as mandatory or non-mandatory.This field is now configured based on the settings defined in SailPoint. The global comments field provides the ability to make changes in all requested/review line items. Admins can now decide to either pre-fill the comments with standard text that can be customized via the SetUp page. > [!NOTE] > > Prior to version 3.0, the comments field in ServiceNow auto filled with a standard text while requesting access. Now, using the global comment field will write to all line items. Color legend for the comment icon in the Request/Review Access UI: 1. Red - Mandatory and empty 2. Grey - Non-mandatory and empty 3. Primary Color of the ServiceNow instance - Comment field has text filled. > **Screenshot** > > [![Config Comments]()]() 4. The comments field can be set with a default text value for each of the line items through the SetUp page, however, this can be changed by admins. 5. Comment Configuration of the line item will reflect the behavior (mandatory or non-mandatory) based on the settings in SailPoint if the field is left empty in the setup page. ### How to Enable Comment Configuration 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 2. Go to settings with the label, **Default comments for requested items. Keep it blank to impose comment configuration of IDN**. 1. The default text included is "ServiceNow SailPoint Catalog Integration – Default Comments" to enable compatibility for versions prior to v3.0. This text can be updated as per your organization standards. 2. Leave it blank to impose comment configuration of SailPoint. 3. Users have the ability to copy comments across all line items during request/review using the **Global Comments** functionality. 4. The comment icon in the top right of the page is the **Global Comments** field. A change made to this field will reflect the same text to the comment fields of all the line items on that page. > [!NOTE] > > **Screenshot** > > [![Copy of Commentt]()]() > [!NOTE] > > **Screenshot** > > [![Copy of Comment1]()]() > [!NOTE] > > **Screenshot** > > [![Copy of Comment2]()]() > [!NOTE] > > Any changes made to individual line items will also be overwritten by making edits to the **Global Comments** field. ## Configuring Multi Account The Multi Account Support Enabled setting on the Setup page directly controls the account selection behavior within the "Request and Review Access" process. ### When Multi Account Support Is Enabled - Setting this property to Yes activates the account selection feature for widget-based requests, prompting the requester to choose a specific target account when a user has multiple accounts on a source. - During the "Review and Submit" step, the system requires the requester to select a target account for any line item with multiple account or revoke assignment options. A selection is mandatory before the request can be submitted. > **Screenshot** > > [![Multi account yes 1]()]() - For already assigned access, request submission will be successful and the following automated actions occur: - The Access Request in SailPoint is immediately canceled. - SailPoint logs the reason with the message: “Already has access to this item, only access remove date can be modified.” > **Screenshot** > > [![Multi account No]()]() > **Note** > > The Identity Security Catalog Application currently does not support submitting a request to change the expiration date of access that is already assigned. 3. The original request (REQ) in ServiceNow is closed with an "Incomplete" status. ### When Multi Account Support Is Disabled Setting the Multi Account Support Enabled property to No deactivates the Multi Account functionality and reverts to the standard request behavior: - The system does not trigger the account selection feature. All requests follow the standard, single-account submission flow. - During the "Review and Submit" step, the system no longer prompts the requester to select an account or revoke assignment, even if multiple options are technically available. The request is being submitted for the main identity that you selected from the catalog. This is the central identity in SailPoint to which all of the user's other accounts are related. > **Screenshot** > > [![Mutli accuont no 1]()]() - If a user attempts to request access they already have, the submission will fail. The system actively blocks the request and displays a validation error message: “The selected access is already assigned.” > **Screenshot** > > [![Multi account yes]()]() ## Linking with the SailPoint for Service Desk Application If you have both the SailPoint Identity Security Cloud for Service Catalog and SailPoint for Service Desk store applications installed on the same ServiceNow instance, you can link the tickets created by both of these applications. The default set up links both of these tickets using the `parent` field on tickets created by SailPoint for Service Desk so you can use Out Of The Box (OOTB) related lists to show the linked records on requested items created by SailPoint Identity Security Cloud for Service Catalog. > [!IMPORTANT] > > The minimum supported version for the SailPoint Service Desk Application is version 1.1.0. ### Set-Up for the SailPoint Identity Security Cloud for Service Catalog Application 1. Sign in to your ServiceNow instance as an administrator, and go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. > **Screenshot** > > [![Copy of q]()]() 1. Scroll on the page to find the **Specify the field name that will be used to store access request ID from SailPoint** property. > **Screenshot** > > [![Copy of r]()]() 1. The default value is set to `correlation_id`. Update the value to a different field from the Requested Item table (sc\_req\_item), if you are using `correlation_id` for another integration. > **Note** > > The value in this field will be overwritten by the integration, so you must ensure the value is not used by any OOTB or custom code. 1. Select **Save**, and follow the steps for [Linking with SailPoint Service Catalog](). ## ISC Event Processing Table Cleaner The ISC Event Processing Table Cleaner removes old records from the `x_sap_intidn_isc_event_processing` table. The default retention period is 7 days. Retention is stored in the Age in seconds field. For example, 604800 seconds equals 7 days. The Data Management Policy is inactive by default. Activate the policy and the table cleaner rule, then set the retention period to match your organization's policy. > [!NOTE] > > The ISC Event Processing table receives a large volume of events. SailPoint recommends an active Data Management Policy to reduce performance impact. ### Configuring the ISC Event Processing Table Cleaner 1. Go to **SailPoint Identity Security Cloud \> ISC Events \> Event Processing Table Cleaner**. 2. Activate the Data Management Policy. 3. Activate the table cleaner rule. 4. Set Age in seconds to the retention period your organization requires. > [!NOTE] > > **Screenshot** > > [![Copy of ISC Event Processing Table Cleaner]()]() ## ISC Backup Utility The ISC Backup Utility is a scheduled job. It polls SailPoint for access request status and pending approvals, then updates the corresponding ServiceNow records. Use this job to reconcile events that SailPoint did not deliver to ServiceNow, for example during a connectivity interruption or a failed event delivery. Without it, a catalog request that missed a real-time event can remain at its last known status even though the request has progressed in SailPoint. The job is inactive by default. Run it on demand when events are not in sync. Investigate why records are not synchronizing, and use this utility only until that issue is resolved. ### How to Configure the ISC Backup Utility 1. Go to SailPoint Identity Security Cloud \> ISC Events \> Backup Utility Scheduled Job. 2. Open ISC Backup Utility - Access Request Status and Pending Approval Sync. 3. Run the job, or schedule it every 15 to 30 minute if events are not processing.. > **Screenshot** > > [![Copy of ISC Backup Utility]()]() # Configuring the SailPoint Access Page Versions 3.2 and prior feature a single landing page named `Manage_Access`. Access to this page is defined and restricted to roles authorized by the ServiceNow administrator. An example to provide a link to this page is explained in [Manage Access](<#manage-access>). SailPoint recommends admins evaluate the best option on the ServicePortal or Employee Center to provide the link to access the `Manage_Access` page according to the organization's portals. > [!NOTE] > > `Manage_Access` will have limited changes post v3.2. Admins are advised to migrate to widgets via pages/record producers introduced from v4.0 to use the latest architecture and functionality benefits. Version v4.0 has transformed the application architecture by introducing widgets for enhanced flexibility. These widgets collaborate seamlessly throughout a page to deliver the SailPoint Access Request solution. This update offers a plethora of opportunities to tailor the request page to align with specific business requirements. Moreover, it grants ServiceNow developers the flexibility to personalize the request process, mirroring ServiceNow's widget concept. Moving forward post version 4.0, users will have access to multiple widgets catering to similar functions. ServiceNow developers can select the most suitable widgets to integrate into customized request pages. By default, widgets are set to Read-Only, prompting users to duplicate them for customization purposes. SailPoint furnishes sample pages and record producers, detailed in the subsequent section, that can be tailored by ServiceNow implementers to meet organizational needs. These pages are accessible through ServicePortal or the Employee Center, dependent on the specific implementation requirements. ServiceNow administrators must adjust the properties according to the choice of utilizing Manage Access, ISC Request, Record Producer, or ISC Certification. ## SailPoint Demo Pages The **SailPoint Demo** category has been included to the Service Catalog, featuring links to all custom pages and record producers provided Out Of The Box (OOTB). Users with the `x_sap_intidn.sapadmin` role can view this category and customize it according to their needs. > [!NOTE] > > **Screenshot** > > [![SailPoint Demo category]()]() ## Manage Access As an Administrator, you must add a **Manage Access** link to the Service Portal menu that users select to request access, as this is not done automatically via the app installation. Change the application scope to **Global**, then follow the process described to add a manage access link for users to request access. To update the Service Portal Menu: 1. Use the search filter to search for **Service Portal**, then select **Portals** in the menu. > **Screenshot** > > [![Service Portal search results]()]() 2. Select the **Service Portal** link listed to view its details. 3. Select the Info icon on the **Main menu** and select **Open Record** in the **Instance with Menu** dialog. > **Screenshot** > > [![Open the Service Portal menu record]()]() 4. Locate the **New** button in the Widget section and select it to add a **Manage Access** (or similar) menu item for users to request the access they need. > **Screenshot** > > [![Add a Manage Access menu item]()]() 5. Add the new menu item as follows: **Label**: Enter **Manage Access** or a similar label for the menu item to give users the ability to request access. **Type**: Select **URL** from the list. **HREF / URL**: Enter the value required for the integration to work correctly: `?id=manage_access` **Condition**: Enter the value required for the integration to work correctly in this field: `GlideSPScriptable.canSeePage("manage_access")` > **Screenshot** > > [![Manage Access menu item settings]()]() 6. Select **Submit** to save changes and create the **Manage Access** menu item. > **Screenshot** > > [![Updated Service Portal menu]()]() ## ISC Request As an Administrator, you’ll need to add one of the SailPoint request page links to the Service Portal or Employee Center menu that users select to request access, as this is not done automatically via the app installation. - Page 1: Title: ISC Request, Application: SailPoint IdentityNow for Service Catalog - Page 2: Title: ISC Request 2, Application: SailPoint IdentityNow for Service Catalog The pages can be used as is, however, SailPoint suggests you change them as per your theme, branding, and combination of suitable widgets. > [!NOTE] > > Widgets on the page can be moved around using Studio and by modifying the CSS along with the appropriate widget options. Changes to the widgets can be made by making a copy of these Read-Only widgets and applying them back to your pages. ## ISC Certification As an Administrator, you’ll need to add the SailPoint Certification page link to the Service Portal or Employee Center menu that users select to request access, as this is not done automatically via the app installation. - Page: Title: ISC Certification, Application: SailPoint IdentityNow for Service Catalog The page can be used as is, however, SailPoint suggests you change it as per your theme, branding, and combination of suitable widgets. > [!NOTE] > > Widgets on the page can be moved around using Studio and by modifying the CSS along with the appropriate widget options. Changes to the widgets can be made by making a copy of these Read-Only widgets and applying them back to your page. ### Redirect SailPoint Certification Due Notifications Redirect the SailPoint Certification Due Notifications to ServiceNow `https:///sp?id=isc_certification` by modification of the notification template [https://{tenant}.identitynow.com/ui/a/admin/global/email-templates/default/certification\_due]() ## SailPoint Record Producer As an Administrator, you can let users request SailPoint entitlements via Record Producer view. The following Record Producers are added as part of the application. In the **Accessibility** tab, an end users **Catalogs** field is set as **Service Catalog**, and the **Category** is **Can We Help You?**. This may change based on your setup. > [!NOTE] > > **Screenshot** > > [![SailPoint Record Producer]()]() - Page 1: Name: Title: SailPoint Access Request, Application: SailPoint IdentityNow for Service Catalog - Page 1: Name: Title: SailPoint Access Request 2, Application: SailPoint IdentityNow for Service Catalog The Record Producers can be used as is, however, SailPoint suggests you change them as per your theme, branding, and combination of suitable widgets. > [!NOTE] > > Changes to the widgets can be made by making a copy of these Read-Only widgets and applying them back to your pages. ### Applying Widget Options in Record Producers 1. Go to **Record Producer**, and select **Widget** from the variables related list. 2. In the **Default Value** tab, add or modify the JSON values. 3. **Save** the changes. > [!NOTE] > > Record producer has the ability to attach attachments along with SailPoint record producers. The **Default Attachment** option needs to be selected. Every attachment in the record producer's record will be duplicated to the corresponding RITM records. # Configuring Connection Parameters SailPoint and ServiceNow need to be configured for the connection to enable the exchange of seamless data. SailPoint uses the industry standard OAuth 2.0 framework’s following grant types: Service Account (previously referred as Client Credentials) and User Account (previously referred as Authorization Code). One or more of the methods must be chosen for the connection based on your organization's preference. This page lists the possible grant types, and the following pages give step by step instructions for the admins. - **Service Account** (Previously referred as Client Credentials) - The Service Account connects ServiceNow to SailPoint with one specific service account. All ServiceNow users use this preconfigured account when signing in as a SailPoint user. All access requests are made from the ServiceNow Service Catalog app, and are generated on behalf of one specific service account user in SailPoint. This service account user must have the ORG\_ADMIN role with SCOPE:All that allows to call the REST API endpoints without any consideration for limitation of authorization. The features related to limitation of authorization are programmatically controlled in the app. SailPoint considers the source of all interactions with ServiceNow as the service account. For example, the `requester name` in SailPoint will show as `Service Account` and not the user who initiated the request in ServiceNow. Traceability of the request to the user requires additional steps. ServiceNow users have seamless authorization using the SailPoint app on ServiceNow, while connected to SailPoint. - **User Account** (Previously referred as Authorization Code) - The User Account connects ServiceNow to SailPoint after authentication of the logged in ServiceNow user via the OAuth server. In this case, SailPoint is logged in via the actual user and not the service account. SailPoint requests are raised using real SailPoint users. ServiceNow users will see an authorization prompt when using this option in ServiceNow. You can configure the frequency of the prompt to be shown only once or multiple times. Requests via ServiceNow are based on settings in SailPoint, therefore, the ability to request for others depends on privileges of that specific user in SailPoint. Here, the `requester name` in SailPoint will show as `requester account`. Approval actions still follow the `Service Account`. > **Note** > > - There are some minor feature differences between the two connection methods especially related to transfer of variables across the systems. > - The `Approve` and `Reject` requests made under the [IDN Workflow]() approval type are handled by client credentials rather than the real user, therefore the display of the IDN values will be as per client credentials. - **User Account for Certifications** - The Certifications module uses only the Authorization Code connection mechanism. This is independent of the request access connection and is required to setup only if Certification in ServiceNow is used. > [!IMPORTANT] > > ServiceNow connects to SailPoint via APIs. This list must be kept current with installations and upgrades. For more information about APIs applicable to the appropriate version, refer to [Identity Security Cloud Links](). ## Service Account Configuration (Previously referred as Client Credentials for Access request) To configure the access request connection using client credentials, perform the following: 1. Generate a personal access token on SailPoint. 1. Sign in to SailPoint as an administrator. 2. Follow the instructions to [Generate a Personal Access Token](). For additional information, refer [to Best Practice: Using Personal Access Tokens](). 3. A client ID and client secret are generated for you. 4. Save these offline so they are accessible. > **Note** > > No additional configuration is required on the ServiceNow side to support client\_credentials. 2. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 3. Enter the fully- qualified domain name of your SailPoint tenant in **Identity Security Cloud URL** (Mandatory). For example, `https://.api.identitynow.com` 4. Enter the values of the **Client ID** and **Client Secret** that you generated in the above step in **Identity Security Cloud Personal Access Token Client ID** (To be Deprecated from future release, Use Application Registries) and **Identity Security Cloud Personal Access Token Client Secret** (To be Deprecated from future release, Use Application Registries). > **Note** > > This is the legacy method to establish the Service Account and will be soon deprecated. Keep this blank if you are using the new method as described in point 5. 5. Enter the the value of the Auth name from the application registries in **Application Registries OAuth Provider Name for Service Account** (Provides enhanced performance, Mandatory from future release). To configure the parameter perform the following steps. (It is required for app version 5.3 and future releases.) 1. In ServiceNow, go to **System OAuth \> Application Registry**. 2. Select **New**. Choose **Connect to a third-party OAuth provider**. 3. Enter the **Client ID** and **Client Secret** you created in step 1. 4. Set **Grant Type** to **Client Credentials**, add the **Token URL**, and select **Save**. > **Note** > > This is suggested new method to be mandated from upcoming release. Keep it blank if still using legacy method as described in point 4. 6. Select client\_credentials if Service Account is the method for connection for every user or Select authorization\_code if individual user account will be used for connection. > [!NOTE] > > **Screenshot** > > [![Service account connection settings]()]() ## User Account Configuration (Previously referred as “Auth Code for Access Request) To configure the access request connection using authorization code, perform the following: 1. Sign in to SailPoint and create a new OAuth client. Go to **Admin \> Global \> Security Settings \> API Management \> New**. 2. Type a name in the **Description** and select the options for **Refresh token** and **Authorization Code**. 3. Enter the **Redirect URL**, and type the word `Scope` into the **Scopes** field. Enable the option for `sp:scopes:all` to turn it **ON**. 4. Select **Create**, and save the **Client ID** and **Client Secret** for configuration on the ServiceNow side. > **Screenshot** > > [![Identity Security Cloud OAuth client]()]() 5. In ServiceNow, go to **System OAuth \> Application Registry**, and then select **New**. 6. On the interceptor page, select **Connect to a third-party OAuth provider**, and then fill in the form fields. - **Name**: The name you want to give the OAuth client. For example, IDN. - **Client ID**: The client ID of the application registered in SailPoint; created in step 4. - **Client Secret**: The client secret of the application registered in SailPoint; created in step 4. - **Default Grant type**: Authorization code. - **Refresh Token Lifespan**: Auto populates the seconds. You may customize the value as needed. - **Active**: Checked. - **Authorization URL**: `https://{{ORG_NAME}}.identitynow.com/oauth/authorize` - `{{ORG_NAME}}`: The name of the SailPoint tenant. - You can check the relevant configuration of your SailPoint tenant at the following link. Replace {{ORG\_NAME}} with the name of your organization: `https://{{ORG_NAME}}.api.identitynow.com/oauth/info` - **Token URL**: `https://{{ORG_NAME}}.api.identitynow.com/oauth/token` - `{{ORG_NAME}}`: The name of the SailPoint tenant. - **Redirect URL**: `https://{{SERVICE_NOW_INSTANCE_HOST}}/oauth_redirect.do` - `{{SERVICE_NOW_INSTANCE_HOST}}`: The hostname of the ServiceNow instance. > **Screenshot** > > [![ServiceNow OAuth application registry form]()]() 7. Generate a Personal Access Token on SailPoint. - Sign in to SailPoint as an administrator. - Follow the instructions to [Generate a Personal Access Token](). For additional information, refer to [Best Practice: Using Personal Access Tokens](). - A Client ID and Client Secret are generated for you. Save these offline, so they are accessible. 8. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 9. Enter the fully-qualified domain name of your SailPoint tenant in **Identity Security Cloud URL** (Mandatory). For example, `https://.api.identitynow.com` 10. Enter the values of the **Client ID** and **Client Secret** that you generated in the above step \#7 in **Identity Security Cloud Personal Access Token Client ID** (To be Deprecated from future release, Use Application Registries) and **Identity Security Cloud Personal Access Token Client Secret** (To be Deprecated from future release, Use Application Registries). 11. Select `client_credentials` if Service Account is the method for connection for every user or select `authorization_code` if individual user account will be used for connection. 12. In **Application Registries OAuth Provider Name for "Logged In User Account"** (Mandatory if User Authorization is "Logged In User Account", i.e authorization\_code) enter the name you gave the OAuth client in step 6. > **Screenshot** > > [![Logged in user account authorization code setting]()]() 13. Assign the appropriate role on ServiceNow to a user to access the portal. For more information on the appropriate role, refer to [Assigning Roles Required to Access the Portal Integration to ServiceNow Users](). 14. Sign in with the SailPoint user that has the required privileges for intended operations. > **Screenshot** > > [![Identity Security Cloud sign in]()]() ## User Account for Certification (Previously referred as Auth Code for Certification) To configure the connection using authorization code for the Certification interface, you can use the OAuth2 connection defined in User Account Configuration or create a new one. This can be ignored if the Certification functionality is not being configured for the ServiceNow instance. > [!NOTE] > > When the same OAuth client is used for both the **User Authorization validation method** and the **Application Registries OAuth Provider Name for Certification**, the user's authentication session is shared across both the **SailPoint Access Request** and the **Certification Page**. To configure the Certification connection using authorization code, perform the following: 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 2. If not filled already, enter the fully-qualified domain name of your SailPoint tenant in **Identity Security Cloud URL**. For example, `https://.api.identitynow.com` 3. Enter the values of the Client ID and Client Secret that you generated in the above step in **Identity Security Cloud Personal Access Token Client ID** (To be Deprecated from future release, Use Application Registries) and **Identity Security Cloud Personal Access Token Client Secret** (To be Deprecated from future release, Use Application Registries) or Enter the the value of the Auth name from the application registries in **Application Registries OAuth Provider Name for Service Account** (Provides enhanced performance, Mandatory from future release). 4. In **Application Registries OAuth Provider Name for Certification** (Mandatory if using Certification widgets), enter the name of the OAuth Client. The scope can be limited to `iai:decisions:manage`. > **Screenshot** > > [![OAuth provider name for certification]()]() 5. Assign the appropriate role on ServiceNow to a user to access the portal. For more information on the appropriate role, refer to [Assigning Roles to the Portal Integration](). 6. Sign in with the SailPoint user that has the required privileges for intended operations. ## Configuring ISC Event Triggers Starting in version 5.4, the Service Catalog application uses SailPoint event triggers instead of timer-based polling. The triggers push approval and access request updates to ServiceNow in real time. > [!IMPORTANT] > > This configuration is required starting in version 5.4. Approval synchronization and access request status updates do not work without it. Before you begin: 1. In ServiceNow, create an integration user with the `rest_service`, `x_sap_intidn.user`, and `itil` roles. 2. Set the user's identity type to **Machine** and select **Web services access only**. 3. Use this user's credentials when you configure the SailPoint subscriptions. ### Integration URL Replace `{instance_name}` with your ServiceNow instance name: `https://{instance_name}.service-now.com/api/x_sap_intidn/isc_event_processor` ### Required Subscriptions Create an HTTP subscription in SailPoint for each of the following triggers. Use the integration URL and the ServiceNow integration user credentials for every subscription. | \# | Trigger | Subscription type | Filter | | --- | --- | --- | --- | | 1 | ServiceNow Approval Request Created for Service Catalog | HTTP | `$.attributes.clientMetadata[?(@.origin == 'ServiceNow Service Catalog Integration')]` | | 2 | ServiceNow Approval Request Updated for Service Catalog | HTTP | `$.attributes.clientMetadata[?(@.origin == 'ServiceNow Service Catalog Integration')]` | | 3 | ServiceNow Access Request Completed for Service Catalog | HTTP | `$.accessRequestItems[?(@.clientMetadata.origin == 'ServiceNow Service Catalog Integration')]` | | 4 | ServiceNow Access Request Cancelled for Service Catalog | HTTP | `$.accessRequestItems[?(@.clientMetadata.origin == 'ServiceNow Service Catalog Integration')]` | | 5 | Access Request Decision | HTTP | `$.requestedItemsStatus[?(@.clientMetadata.origin == "ServiceNow Service Catalog Integration")]` | To validate the triggers: 1. In the SailPoint admin interface, go to **Subscriptions**. 2. For a subscription, select the ellipsis icon, then select **Test Subscription**. 3. In ServiceNow, go to **SailPoint Identity Security Cloud \> ISC Events \> ISC Event Processings** and confirm that the test event appears. 4. Repeat these steps for all five subscriptions. # Configuring Other Parameters There are other important parameters in addition to the connection parameters for the ServiceNow admin to configure. 1. Enter the **SailPoint attribute to correlate with ServiceNow account**. For example, `name` or `accountId`. To help ensure successful attribute correlation, you must use the exact name for the attribute as it appears in SailPoint in parenthesis (not the "friendly name" that’s displayed for the identity profile) and you must prefix any second level or custom fields with `attributes`. > **Note** > > An understanding of the data model used to organize your data in SailPoint will help ensure you specify the correct value. Refer to the table of attributes in [Second-level Fields for Identities]() for more information. 1. Enter the **ServiceNow Account attribute to correlate with the SailPoint Identity Cube**. For example, `user_name`. > **Note** > > The values of attributes being correlated as a result of mapping a SailPoint attribute and a ServiceNow account attribute are treated as case-insensitive. 1. Select your choice from **Approval Flow**. The integration relies on ServiceNow Manager approvals before it can create access requests in SailPoint. 1. To use a SailPoint approval workflow instead, select `None`. 2. To use only ServiceNow as a manager in ServiceNow, use `Manager Approval` (Option included to maintain compatibility to earlier versions, soon to be deprecated). 3. To use the easy to configure and native ServiceNow approvals, use `Configurable Approvals` from the **Approval Flow** list. For more information, refer to [Configuring Approval Flow](). 2. Select your choice for **Generic Approval Definition Enabled** (applicable if Configurable Approvals is selected for Approval Flow). For more information, refer to [Generic Approval Definition](). 3. Select your choice for **Multi Account support enabled**. Set the “Multi Account support enabled” property to “Yes” to activate the feature. For more information, refer to [Configuring Multi Account.]() > **Screenshot** > > [![Product feature]()]() 1. Set the configuration for the **Default comments for requested items**. Keep it blank to impose comment configuration of SailPoint. For more information, refer to [Configuration of the Comments Field](). 2. Select your choice for **Is Sunset Date Mandatory for Access Requests?** For more information, refer to [Configuration of the Sunset Date Field](). 3. Select your choice for **Skip user selection screen for users who can request access for self only**. If the user will select access only for themselves, leave the default value as `Yes`. This bypasses the user selection screen and redirects them to the sign in page. If the user needs to be able to request access for others, change the value to `No`. This requires the user to select a user before it redirects them to the sign in page. 4. **Enter page URL to redirect after submission** (Default: Service Portal page). This is where you want your user to be redirected after successfully creating a new ServiceNow Access request. For example, 5. You can leave the field empty to redirect the user to the default Service Portal page. 6. You can specify a relative path that starts with / to redirect the user to that page. For example, to send a user to the Manage Access page use `/sp?id=manage_access`. 7. You can enter a URL with an absolute path to a page or site. For example, `https://www.sailpoint.com/` 10. Enter a user-friendly **Header that will be displayed in the sidebar**. For example, `SailPoint Identity Security Cloud for Service Catalog`. 11. Select your choice for **Show Header text box?** Instructional text in the remaining customizable header fields will be applicable based on your choice: 1. **User Header text** 2. **Add Access Header text** 3. **Recommendations Header text** 4. **Remove Access Header text** 5. **Review & Submit Header text**. For more information, refer to [Configuring Page Headers](). 12. Select whether you want to **Display Non-Requestable Access Objects** or not. 13. Set the configuration for **List and order of Search results tab. Exact text separated by comma to be used.** (For manage\_access page and Native search only) For more information refer to [Configuring the Search Results Tab]() 14. Enter additional query conditions for **Additional query for fetching list of access profiles**, **Additional query for fetching list of roles**, and **Additional query for fetching list of entitlements**. Through these, the admin user can filter Roles, Access Profiles and Entitlements using any attribute the access object has. Only those filtered values will be available for end users. By default, these fields are empty. Examples of a query condition > **Screenshot** > > [![Copy of Additional query for fetching]()]() > **Screenshot** > > [![Copy of Param AP]()]() > **Screenshot** > > [![Copy of Param R]()]() > **Screenshot** > > [![Copy of Param Ent]()]() > **Note** > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. 1. Enter the number of search results in **Count of displayed access profiles/roles/entitlements on one page (Max 250)** > **Screenshot** > > [![Manage Access Page Configuration To be Deprecated from future release1]()]() 1. **Enter user attributes to display on user selection screen (separated by comma)**.These are the attributes you want to make available on the users search page. Use field names from the `sys_user table` separated by a comma. > **Note** > > For both SailPoint Access Request 2 and ISC Request Sample 2 widgets, ensure that the attributes configured under **Display Fields** exactly match the field names available in the `sys_user` table. Configure only those attributes that exist as valid fields in the `sys_user` table. 4. **Enter user attributes to search by on user selection screen (separated by a comma)**. These are the attributes you want to use for the users search page. Use fields names from the `sys_user table` separated by a comma. 5. Select how you want to manage **Separation of Duties policy checks** for the selected users before a new access request can be raised. For example, - **Disabled** (default) - There is no Separation of Duties violation check for the selected users. - **Soft: allow submission** - The Separation of Duties violation check is applied for all the selected users. If there is a violation, a warning message is displayed and the request can be submitted. - **Hard: reject submission** - The Separation of Duties violation check is applied for all the selected users. If there is a violation, an error message is displayed and the request cannot be submitted. 6. To show the recommendations tab, select `Yes` for **Show Recommendations, applicable only if required license available** This property is applicable only if a required license is available. 7. **Specify the field name that will be used to store the access request ID from SailPoint**. This field name is used to link tickets created by `SailPoint Identity Security Cloud for ServiceNow Catalog` with those created for the same request by `SailPoint for Service Desk`. This property is applicable only if you have both the `SailPoint Identity Security Cloud for Service Catalog` and `SailPoint for Service Desk` store applications installed on the same ServiceNow instance. The default value is `correlation_id`. You can change it to another custom field if you are already using `correlation_id` on requested item for other integration. For more information, refer to [Linking with the SailPoint for Service Desk Application](). 8. **Specify the value for status check timer activity in minutes. Default value is 1440 minutes which is 24 hours** The default configuration for the workflow involves pooling statuses from SailPoint once every 24 hours. However, this can be adjusted to align with specific business requirements using the provided property. > **Important** > > Exercise caution when adjusting this value, as setting it too low may lead to requests being canceled. Recommended value: no less than 720. > **Note** > > For app version 3.1.0 and earlier, the required steps are outlined in [Configure Status Pooling Timer](). 1. The **Auto Approve Enabled** field is applicable to customers with app version 3.2.0 and later. The default setting is `No`. If `Yes` is selected, the approval request will be auto-approved if the `approver` and `requester/requested for` are the same user. > **Note** > > - This property applies exclusively to the rule types of `ServiceNow User`, `ServiceNow Manager`, `Identity Security Cloud Owner` and `Identity Security Cloud Manager`. > - The property does not apply to `ServiceNow Workflow`, `ServiceNow Flow`, and `Identity Security Cloud Workflow`. 9. The **Property to determine which logs to print. Choices are debug, info, warn and error. Default is warn** is used to determine the level of logging. For more information, refer to [Debug and Error Handlers](<#reports-debug-and-error-handlers>). 10. The **Native Search Redirect Page ID (example: manage\_access)** setting is useful if Native Search is implemented. For more information, refer to [Configuring Native Search](). 11. Select **Save**. ## Application Level Configuration Refer to [Application Level Configuration]() for more information. ## Employee Service Center Portal Configuration The Manage Access request page can now also be included with the Employee Service Center portal. > [!NOTE] > > SailPoint has configured and supports only the ServiceNow out-of-the-box Employee Center (EC) theme of the Employee Service Center (ESC). Issues related to custom changes to the EC theme or other themes are not supported. ### Creating a Quick Link Record A quick link to the Manage Access page must be manually configured in the Employee Service Center because this is not an automatic process during app installation. > [!NOTE] > > The process outlined may vary based on your configuration. 1. Sign in as an administrator, and change the application scope to **Global**. 2. Go to the application navigator, enter `Quick Links` in the filter navigator, and open the **Employee Center** `Quick Links` menu. > **Screenshot** > > [![Employee Center Quick Links menu]()]() 3. Select **New**, and enter the following details: 1. **Content type** - Page 2. **Page** - manage\_access 3. Provide a **Quick link name** and **Title**. 4. Ensure it is marked as **Active**. 5. (Optional) Provide a background image. > **Screenshot** > > [![Quick Link record]()]() 4. Select **Submit**. 5. Go to the Employee Center homepage by entering [https://instance-name.service-now.com/esc]() in the browser. 6. Select the logo in the top-left corner. This ensures that the redirect homepage is selected while adding the quick link widget. > **Screenshot** > > [![Employee Center homepage]()]() 7. Highlight the homepage ID from the URL after `id=` and copy it. > **Screenshot** > > [![Employee Center homepage ID]()]() 8. Change the application scope to `Employee Center` or `Employee Center Pro` depending on which scope your homepage is in. In this example, change to the `Employee Center Pro` scope. 9. Use the application navigator to open `Service Portal Configuration`, and then select **Designer** from the options shown. > **Screenshot** > > [![Service Portal Configuration]()]() > **Screenshot** > > [![Service Portal Designer]()]() 10. Paste the copied homepage ID to search for it. > **Screenshot** > > [![Searching for the homepage]()]() 11. Select the `Pencil` icon in the **Quick Links** widget. If the widget is not already listed on your homepage, search for it in the `Widgets` list on the left-hand side and add it to the page. > **Screenshot** > > [![Quick Links widget]()]() 12. In the widget instance pop-up, look for **Quick links**. > **Screenshot** > > [![Quick Links widget instance]()]() 13. Search for the newly created **Quick links** entry and select **Save**. > **Screenshot** > > [![Selecting the Quick Links entry]()]() 14. Confirm that the Manage Access quick link is available on the homepage. > **Screenshot** > > [![Manage Access quick link]()]() ## Reports, Debug and Error Handlers Admins and users with appropriate access to `SailPoint Access Request - Service Catalog` can reference end user requests via the **Requested SailPoint Items** report. To access the report, go to **SailPoint Identity Security Cloud \> Requested SailPoint Items** in the fulfiller view. A list will display the active user requests and their SailPoint correlation IDs that were created within the instance for `SailPoint Access Request - Service Catalog`. > [!NOTE] > > **Screenshot** > > [![logs1]()]() Visible columns include **Correlation ID**, which stores the request ID generated in SailPoint, along with all the variables displayed as columns. > [!NOTE] > > **Screenshot** > > [![Correlation ID]()]() Pages using widgetized code introduced from v4.0 will have the ability to display a varying level of debug and error messages. These play a crucial role to pinpoint bugs, troubleshoot issues, and ensure the stability. Log levels can be configured to `Debug`, `Info`, `Warn` and `Error`. The default and suggested value is `Warn`. ServiceNow displays a specific error type along with all error types that are higher in the hierarchy. The default error log hierarchy is as follows: `Error > Warn > Info > Debug`. Therefore, when the default value is set to `Warn`, both errors and warnings will be recorded in the ServiceNow logs table. Setting the property to `Debug` will lead to an increased number of messages appearing in the logs table. It is recommended to use this setting judiciously, particularly when diagnosing a specific issue. Admins have the option to select the **Logs** link to specifically identify errors associated with this application, in addition to the standard ServiceNow system logs table. > [!NOTE] > > **Screenshot** > > [![logs]()]() This table lists the specific errors that the widgetized SailPoint Service Connector code, implemented in version 4.0, will log. | Code | Type | Message | Resolution details | | --- | --- | --- | --- | | ISC0001 | ERROR | Catalog item is missing, please check with your administrator | Verify that the necessary catalog item - `'Sailpoint Access Request - Service Catalog' (sys-id: xxxx)` is present, active and requestable in your instance. | | ISC0002 | ERROR | Missing connection parameters, please check with your administrator | Verify that all the connection properties including `'x_sap_intidn.x_sp_spnt_snow_int.spnt_endpoint_url'`, `'x_sap_intidn.x_sp_spnt_snow_int.spnt_client_id'`, and `'x_sap_intidn.x_sp_spnt_snow_int.spnt_client_secret'` are present and correctly filled in. | | ISC0003 | ERROR | Cannot connect to the target instance, please check with your administrator | There is an issue connecting to the target instance with the provided `client_id` and `client_secret`. Ensure that the provided values are correct. | | ISC0004 | ERROR | Method failed to complete | A specific error/exception has occurred while execution. Refer to the `details` attribute logged along with the error to debug further. | | ISC0005 | ERROR | Incorrect field name | An incorrect field name was encountered while trying to fetch user details. Verify the set-up in user display widgets where an incorrect field name was specified. | | ISC0006 | ERROR | Could not find UI Handler | UI Handler is used for communicating between ServiceNow widgets and server side code. Verify that an Extension Point - `ISCUIHandler` exists and there is at least one active implementation present under it. | | ISC0007 | WARNING | Incomplete details received | Incomplete access object details received from SailPoint. Verify the configuration on the SailPoint tenant. | # Configuring Parameters This section groups guidance for connection parameters, other parameters on the Setup page, and application-level configuration. - [Configuring Connection Parameters]() describes the available connection methods between SailPoint and ServiceNow, including the connection used for certifications and event triggers. - [Configuring Other Parameters]() describes additional Setup parameters for correlation, approvals, access requests, and page behavior. - [Application Level Configuration]() covers configuration topics applicable to widgets-based pages and the Manage\_Access page. # Frequently Asked Questions This Frequently Asked Questions (FAQs) section provides answers to the most commonly asked questions for ServiceNow Catalog for Identity Security Cloud. ## Why do expiration dates appear different on ServiceNow and SailPoint ? Answer: The ServiceNow Service Catalog app allows users to select an end date/expiration date while raising a request. A timestamp is not processed in this feature. ServiceNow considers the user’s timezone during date selection. The date is converted to the UTC timezone before being sent across to SailPoint. This conversion happens when the requested item is created and saved in ServiceNow variables in the UTC timezone. > [!NOTE] > > **Screenshot** > > [![Global Sunset Date]()]() ## Can multiple ServiceNow instances connect to a single SailPoint tenant without limitations? Answer: Yes, SailPoint can connect to multiple instances of ServiceNow under certain conditions. To avoid issues, do not make requests from two different ServiceNow instances for the same user. Doing so will cause results to be erratic, and SailPoint is unable to support such cases. ## Can the same set of SailPoint credentials be reused for different ServiceNow instances. Answer: Yes. ## Can I change the view of the page or restore to the previous page? Answer: Yes. You can change the view of the page or restore to the earlier version. To revert to a previous version, ServiceNow admins can perform the following steps ( Newly launched Free text search widget for v5.2 is used as an example here): - Reverting Page Version (Service Portal) 1. Go to **Service Portal \> Portals \> Pages** and open the **ISC Request 2** page. 2. Click **Open in Page Editor**. 3. Open the **Access Object Search** widget instance. 4. Scroll down and change the widget back to **ISC Access Object Search**. - Reverting Record Producer Version 1. Go to **Service Catalog \> Catalog Definitions \> Record Producers** and open SailPoint Access Request 2. 2. In **Variables**, open **Access Object Search**. 3. Under **Type Specifications**, set widget to **ISC Access Object Search**. 4. Under **Default Value**, update the value (refer from original **SailPoint Access Request** record producer). > **Note** > > Reference: > > ServiceNow admins can also use the Version Records feature to revert a configuration back to a specific earlier version. For more information refer to [Revert a change]() # Getting Started with ServiceNow [![SailPoint and ServiceNow]()]() Give your users a seamless employee experience with SailPoint apps on ServiceNow, when your de-facto application for requesting and approving requests is ServiceNow. The SailPoint apps on ServiceNow provide an easy-to-implement, out-of-the-box Identity and Access Management interface with ServiceNow. The SailPoint apps are published in the ServiceNow store and provide multiple integration options, based on your business case. ## Identity Governance Sync user data between SailPoint and ServiceNow. - Users with a Virtual Appliance can refer to [Integrating SailPoint with ServiceNow Identity Governance]() for detailed information. - Users without a Virtual Appliance (also referred to as a SaaS connector) can refer to [Integrating SailPoint with Identity Governance SaaS]() for detailed information. ## Service Desk Raise ServiceNow requests for disconnected applications from SailPoint. Requests can be configured according to your organization's policies and to the features available in ServiceNow. Refer to [Integrating SailPoint with ServiceNow Service Desk]() for detailed information. ## Service Catalog Users can raise requests from ServiceNow, and approvers can approve requests within ServiceNow. Requests for access can be raised for requestable roles, access profiles, and entitlements after Separation of Duties checks, and according to the approval process defined within ServiceNow. Provisioning is initiated in SailPoint, and the status is updated against the request once completed. Refer to [Integrating Identity Security Cloud with ServiceNow Service Catalog]() for detailed information. ## SailPoint Service Catalog AI Assistant Enables users to interact with AI-powered agents to request, manage, and track access through the SailPoint Service Catalog. It provides the conversational AI layer with a chatbot-based experience powered by ServiceNow Now Assist. ### Process Diagram for Catalog App [![Process diagram for the SailPoint Service Catalog AI Assistant]()]() ## Accessing SailPoint Apps [![SailPoint apps on the ServiceNow Now Platform]()]() SailPoint apps for ServiceNow are developed in partnership with ServiceNow on the Now Platform. They are published and available for ServiceNow customers in the [ServiceNow store](). Purchases must be coordinated with your Customer Success Manager or account manager. You can request trials from the ServiceNow store according to [ServiceNow's store policy](). Refer to [Entitlement Process for SailPoint Apps on ServiceNow]() for the detailed entitlement process for SailPoint customers. The ServiceNow store [Help]() page provides generic information about buying, installing, uninstalling, and managing the app. ## Release Information SailPoint continually works to extend the rich experience of core features in apps for ServiceNow. New versions of these apps are regularly released, ensuring compatibility with the latest versions of ServiceNow and SailPoint. ServiceNow also supports deleting accounts. Refer to [What's New in ServiceNow]() for details about recent and upcoming releases for all of SailPoint's ServiceNow solutions. ## Compatibility and Support Matrix SailPoint continually updates support for the apps published in the ServiceNow store to match the ServiceNow support policy and SailPoint releases. SailPoint's ServiceNow team works to announce support for the latest versions within 2 weeks of the General Availability (GA) release of ServiceNow, as well as SailPoint releases. The supported ServiceNow applications and store versions are as follows: | Application | Australia | Zurich | Yokohama | | --- | --- | --- | --- | | Identity Governance | Supported
Store Version 1.0.6 (December 2022) | Supported
Store Version 1.0.6 (December 2022) | Supported
Store Version 1.0.6 (December 2022) | | Service Desk | Supported
Store Version 1.2 (July 2024)
Store Version 1.1 (March 2024) | Supported
Store Version 1.2 (July 2024)
Store Version 1.1 (March 2024) | Supported
Store Version 1.2 (July 2024)
Store Version 1.1 (March 2024) | | Service Catalog | Supported
Store Version 5.2 (May 2026)
Store Version 5.1 (Oct 2025)
Store Version 5.0 (Jul 2025)
Store Version 4.1 (Jan 2025)
Store Version 4.0 (Nov 2024)
Store Version 3.2 (May 2024) | Supported
Store Version 5.2 (May 2026)
Store Version 5.1 (Oct 2025)
Store Version 5.0 (Jul 2025)
Store Version 4.1 (Jan 2025)
Store Version 4.0 (Nov 2024)
Store Version 3.2 (May 2024)
Store Version 3.1 (Dec 2023) | Supported
Store Version 5.2 (May 2026)
Store Version 5.1 (Oct 2025)
Store Version 5.0 (Jul 2025)
Store Version 4.1 (Jan 2025)
Store Version 4.0 (Nov 2024)
Store Version 3.2 (May 2024)
Store Version 3.1 (Dec 2023) | | SailPoint Service Catalog AI Assistant | Supported
Store Version 1.0 (May 2026) | Supported
Store Version 1.0 (May 2026) | \- | ## Integrating SailPoint with ServiceNow Service Catalog > [!NOTE] > > **Integration** > > This is an integration and requires additional licensing or subscriptions to utilize it. For more information, contact your customer success manager. > [!NOTE] > > SailPoint Identity Security is SailPoint's next-generation identity security solution. It encompasses and builds on features and functions from IdentityNow. The product documentation covers both SailPoint Identity Security and IdentityNow features. You may see instances of IdentityNow or Identity Security Cloud in your UI or in the ServiceNow app store for some time. The ServiceNow Portal Integration for Identity Security Cloud enables you to easily add and remove access from ServiceNow accounts. The account information available in ServiceNow is correlated to an identity in SailPoint. You can view the roles and access profiles associated with the identity and use them to manage access. The ServiceNow Certification Portal for Identity Security Cloud enables designated people to review users' access to your enterprise systems and data. Certifiers determine whether the access is appropriate for those users or if access should be revoked. Certifiers will review certifications, approve or revoke access, and sign off on decisions. The ServiceNow Service Portal Integration for [SailPoint]() is a ServiceNow app available in the ServiceNow store. For more information about requesting SailPoint apps from the ServiceNow Store, refer to [How To Experience SailPoint Apps](<#accessing-sailpoint-apps>). > [!NOTE] > > To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes]() page. > [!NOTE] > > Integrating with the ServiceNow Portal is different than using the SailPoint for Service Desk integration that converts SailPoint provisioning activity into tickets in ServiceNow, and requires a SailPoint ServiceNow ServiceDesk license. ## Prerequisites - A supported SailPoint platform - an instance of SailPoint with access requests enabled that you're authorized to access as an administrator. - A supported version of ServiceNow that you're authorized to access as an administrator or to appropriate roles. - A source of ServiceNow accounts that SailPoint can load account information from, so each account can be associated with an identity and access for each identity can be governed. - Permission to manage OAuth 2.0 client applications in ServiceNow. - The endpoint URL of your SailPoint tenant and a supported method for securely connecting to it, such as a Personal Access Token. - After you've configured SailPoint, configure ServiceNow to integrate with the platform. - After you've configured SailPoint, configure SailPoint event triggers. This is mandatory from version 5.4. Refer to [Configuring ISC Event Triggers]() for more information. # Troubleshooting If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support. For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information: - [SailPoint Identity Services Documentation]() - [SailPoint Support Knowledge Base]() - [SailPoint Developer Community]() ## Pending approvals in the workflow are not populated **Issue**: The approval rule configuration does not populate approvals in ServiceNow. **Resolution**: Allow the timer to complete. A new 32 minute timer is present between the **Check for IdentityNow configuration** and **Get IdentityNow Pending Approvals** workflow of `SP_SPNT_SNOW_INT_CreateSailpointAccessRequest`. Additionally, the previous 1 minute timer after the approval request has been updated to 32 minutes for the second level approver and onwards. > [!NOTE] > > **Screenshot** > > [![ISC Workflow 32min]()]() ## Users are not loading on the Manage Access page > [!NOTE] > > **Screenshot** > > [![Manage Access Error]()]() **Resolution**: Perform the following steps to remove the dependency. 1. Sign in to ServiceNow using admin credentials. 2. Change the **Application Scope** to **SailPoint IdentityNow for Service Catalog**. 3. Search widgets in the application navigator, and open the widgets module under **Service Portal**. 4. Open the widget for **Manage SailPoint Access**, and scroll to the dependencies. Select the `ui-select` dependency, then select the **Edit** button. > **Screenshot** > > [![Copy of Manage Access Error1]()]() 5. On the **JS Includes** tab, select the **Edit** button. > **Screenshot** > > [![Copy of Manage Access Error2]()]() 6. From the **JS Includes List**, highlight `angular-sanitize` and press the **\<** button to move it back to the Collection. Select **Save**. > **Screenshot** > > [![Copy of Manage Access Error3]()]() 7. On the widget page for **Manage SailPoint Access**, select the **Update** button. ## Approval request fails with error message **Issue**: The approval request fails with the following error: `Failed creating access request. IDN user session is expired`. **Resolution**: Provide the `x_sap_intidn.user` role to the approvers. ## Recommendations tab visibility issue (app version 3.1) **Issue**: The recommendations tab is visible although you did not opt for an IAI license. **Resolution**: Perform the following steps to update the script and insert a new API link. ### Updating the Script 1. Open ServiceNow as Admin and enter `Script Includes` into the search field. 2. Select **Script Included** under **System Definition**. 3. Open the `SP_SPNT_SNOW_INT_GetOrgInfo` script include. 4. Copy and paste the following code into the script section, and then select **Update**. ```javascript var SP_SPNT_SNOW_INT_GetOrgInfo = Class.create(); SP_SPNT_SNOW_INT_GetOrgInfo.prototype = Object.extendsObject( SP_SPNT_SNOW_INT_Common, { /*_________________________________________________________________ * Description: A method that is calls the API and check if access request recommendation is enabled in IDN * Parameters: void * Returns: boolean ________________________________________________________________*/ isRecommendationEnabled: function() { if (!this.getRecommendationsProductFlag()) { return false; } if (!this.getRecommendationsFeatureFlag()) { return false; } return true; }, /*_________________________________________________________________ * Description: A method that calls the API associated with link 'getTenantInfo' and returns the response for further processing * Parameters: void * Returns: boolean ________________________________________________________________*/ getRecommendationsProductFlag: function() { try { var recProductFlagEnabled = false; var action = 'getTenantInfo'; var accessTokenServiceAccount = this.authScript.getServiceAccountAccessToken(); var request = this.createHttpRequest('GET', action, { headers: { Authorization: 'Bearer ' + accessTokenServiceAccount } }); request.setEndpoint(this.getEndpointUrl(action)); var response = request.execute(); var statusCode = response.getStatusCode(); if (statusCode === 200) { var responseBody = response.getBody(); var res = JSON.parse(responseBody); res.products.forEach(function(product) { if (product.productName == 'iai') { recProductFlagEnabled = product.licenses.some(function(feature) { return feature.licenseId == 'iai:recommendations'; }); } }); return recProductFlagEnabled; } return false; } catch (ex) { gs.error('Error when trying to get product flag info: ' + ex.message); return ''; } }, /*_________________________________________________________________ * Description: A method that calls the API associated with link 'getOrgInfo' and returns the response for further processing * Parameters: void * Returns: Object ________________________________________________________________*/ getRecommendationsFeatureFlag: function() { try { var action = 'getOrgInfo'; var accessTokenServiceAccount = this.authScript.getServiceAccountAccessToken(); var request = this.createHttpRequest('GET', action, { headers: { Authorization: 'Bearer ' + accessTokenServiceAccount } }); request.setEndpoint(this.getEndpointUrl(action)); var response = request.execute(); var statusCode = response.getStatusCode(); if (statusCode === 200) { var responseBody = response.getBody(); var orgInfo = JSON.parse(responseBody); return orgInfo.iaiEnableAccessRequestRecommendations ? true : false; } return false; } catch (ex) { gs.error('Error when trying to get org info: ' + ex.message); return ''; } }, type: 'SP_SPNT_SNOW_INT_GetOrgInfo' } ); ``` ### Inserting a new SailPoint API link 1. Open ServiceNow as Admin and enter `IdentityNow Links` into the search field. 2. Select **IdentityNow Links** under **SailPoint IdentityNow for Service Catalog**. 3. Select the **New** button, and add the following: **Action**: `getTenantInfo` **Link**: `/beta/tenant` > **Screenshot** > > [![AL]()]() 4. Select **Save**. ## ServiceNow approvals are skipped and requested items are canceled (all environments) **Issue**: Inactive members in the SailPoint governance group cause ServiceNow approvals to be skipped and requested items to be canceled. **Resolution**: When the **Approval Flow** is set to `Configurable approval` and the applicable approval definition for an item is set to be `Identity Security Cloud Workflow`, ServiceNow skips the approvals and cancels the requested item. This happens if any of the approvers in the SailPoint governance groups are missing or inactive in ServiceNow. This is the expected behavior as integration expects all of the approvers to be valid in ServiceNow. Perform the following to customize this behavior to allow the approvals to be requested even if only one member of the governance group is present and valid in ServiceNow: 1. Sign in as admin in your ServiceNow instance, and go to **Workflow Editor**. > **Screenshot** > > [![WF]()]() 2. Open the `SP_SPNT_SNOW_INT_CreateSailpointAccessRequest` workflow, and checkout the workflow using the **Checkout** option. > **Screenshot** > > [![WF1]()]() 3. Double-click **Get IDN Pending Approvals** and run the script activity to edit it. > **Screenshot** > > [![WF2]()]() 4. Replace the code in the script tag with the following code. ```javascript (function(current) { workflow.scratchpad.pendingApprovals = []; var approvalsService, action, accessToken, pendingApprovals, grUser, authScript, result, allApproversMissing; approvalsService = new x_sap_intidn.SP_SPNT_SNOW_INT_ApprovalsREST(); authScript = new x_sap_intidn.SP_SPNT_SNOW_INT_Auth(); accessToken = authScript.getServiceAccountAccessToken(); action = current.variables.u_access_action.toString() == 'Add' ? 'GRANT_ACCESS' : 'REVOKE_ACCESS'; pendingApprovals = approvalsService.getPendingApprovalsForRequestedObject(accessToken, current.variables.u_identity_external_id.toString(), current.variables.u_access_id.toString(), action); allApproversMissing = pendingApprovals.length > 0 ? true : false; workflow.scratchpad.autorRejectIdnId = ''; grUser = new GlideRecord('sys_user'); //Validate each individual pending approver record for (var i = 0; i < pendingApprovals.length; i++) { result = approvalsService.getOwnerIdentity(pendingApprovals[i].owner.id.toString()); grUser.initialize(); grUser.addQuery(gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.servicenow_account_attribute'), approvalsService._lookupV2object(result, gs.getProperty('x_sap_intidn.x_sp_spnt_snow_int.spnt_identity_attribute'))); grUser.addActiveQuery(); grUser.query(); if (grUser.hasNext()) { allApproversMissing = false; workflow.scratchpad.autorRejectIdnId = ''; workflow.scratchpad.pendingApprovals.push(pendingApprovals[i]); } else { workflow.scratchpad.autorRejectIdnId = pendingApprovals[i].id.toString(); } } if (allApproversMissing) { workflow.scratchpad.autoRejectIdn = 'true'; workflow.scratchpad.pendingApprovals = pendingApprovals; current.comments = "Approver is skipped from the approval execution plan. Possible reason: Inactive Users"; } })(current); ``` 5. Select **Update**. > **Screenshot** > > [![WF3]()]() 6. Select **Publish** from the menu options. > **Screenshot** > > [![WF4]()]() ### Points to remember - This fix will apply to all the cases where the SailPoint set up has a group. - This is a quick fix specific to your instance, therefore you must reapply the fix during upgrades. ### Version 3.2.0 and Later 1. Sign in as admin on your ServiceNow instance, go to **Application Navigator** and `type sys_extension_instance.LIST`, then press **Enter**. 2. In the newly open tab search for **Point** is `x_sap_intidn.IDNWorkFlowGroupBehaviour`. Two results will be available. 3. Make the row with class name `ProceedForAll` as `active false`. 4. Make the row with class name `ProceedForAnyone` as `active true`. 5. To go backto the original behavior, revert the changes. ## The style for Owner and Source filters is broken (Utah environment) > [!NOTE] > > **Screenshot** > > [![2]()]() **Resolution**: 1. Open ServiceNow as Admin and enter **Widgets** into the search field. 2. Select **Widgets** under Service Portal. 3. Open the **Manage Sailpoint Access** widget. 4. Change the **Application** scope to **SailPoint IdentityNow for Service Catalog**. > **Screenshot** > > [![1]()]() 5. Add the following lines to the end of the CSS: ```css .ui-select-focusser.ui-select-offscreen{ display: none; } ``` > **Screenshot** > > [![3]()]() ## The user data hint is empty when hovering over the user circle (Utah environment) > [!NOTE] > > **Screenshot** > > [![4]()]() **Resolution**: 1. Open ServiceNow as Admin and enter **Widgets** into the search field. 2. Select **Widgets** under Service Portal. 3. Open the **Manage Sailpoint Access** widget. 4. Change the **Application** scope to **SailPoint IdentityNow for Service Catalog**. > **Screenshot** > > [![1]()]() 5. In CSS, search for `.tooltip-inner` and add the following line to the CSS class: ```css white-space: unset; ``` > **Screenshot** > > [![5]()]() ## The Details window launched for Role style is broken (Tokyo and Utah environments) > [!NOTE] > > **Screenshot** > > [![6]()]() **Resolution**: 1. Open ServiceNow as Admin and enter **Widgets** into the search field. 2. Select **Widgets** under Service Portal. 3. Open the **Manage Sailpoint Access** widget. 4. Change the **Application** scope to **SailPoint IdentityNow for Service Catalog**. > **Screenshot** > > [![1]()]() 5. In Body HTML template, search for `modalTemplateAccessProfileDetailsPage2.html` 6. Change the *tag to a span tag in the following two places:* - `` `` - `` `` > **Screenshot** > > [![7]()]() ## Selected user doesn't exist in SailPoint system error. When trying to select a user in ServiceNow Catalog, the following error is displayed: `Selected user doesn't exist in IdentityNow system` **Resolution**: Ensure that all of the links are available in the app, and that none of them are missing. Refer to [Identity Security Cloud Links]() to ensure all links are present and correct for your installed application version. ## Manager header in the user tooltip spans multiple lines in Employee Service Center **Issue**: The tooltip shown while hovering over the selected user has the manager header spanning across two lines. This occurs due to the different CSS applied by ServiceNow in the Service Portal and Employee Service Center. > [!NOTE] > > **Screenshot** > > [![Copy of tooltip]()]() **Resolution**: Use the following steps to update the CSS in the widget. 1. Sign in as admin to the ServiceNow instance, and go **Widgets** under the Service Portal application. > **Screenshot** > > [![Copy of widgets]()]() 2. Search for the Widget named `Manage SailPoint Access` and open the record. > **Screenshot** > > [![Copy of widgets2]()]() 3. In the CSS section of the widget, search for `.item-added-tooltip` > **Screenshot** > > [![Copy of widgets3]()]() 4. Replace the block of 5 lines with the following: ```css .item-added-tooltip { font-size: 14px; min-width: 275px; z-index: 99999; } ``` 5. Select **Update**. > **Screenshot** > > [![Copy of widgets4]()]() ## NOT\_ALL\_ITEMS\_PROVISIONED error or PROVISIONING\_FAILED when raising a second request for the same access profile Error: Access profile user requested has already been in an access with state as NOT\_ALL\_ITEMS\_PROVISIONED.Account Activity Id:xxx **Resolution**: Incorporate the following changes: 1. On the ServiceNow tenant, go to **System Definition \> Scripts Include** and open the `SP_SPNT_SNOW_INT_AccessValidationREST` script. 2. Take a back up of the script. 3. On line number 79 locate one if loop as below - if ( accessRequestStatus\[l\].state != "REQUEST\_COMPLETED" && accessRequestStatus\[l\].state != "REJECTED" && accessRequestStatus\[l\].state != "CANCELLED" && accessRequestStatus\[l\].state != "TERMINATED" && accessRequestStatus\[l\].state != "ERROR" ) 4. Add two more conditions here for NOT\_ALL\_ITEMS\_PROVISIONED and PROVISIONING\_FAILED state as shown below: if ( accessRequestStatus\[l\].state != "REQUEST\_COMPLETED" && accessRequestStatus\[l\].state != "REJECTED" && accessRequestStatus\[l\].state != "CANCELLED" && accessRequestStatus\[l\].state != "TERMINATED" && accessRequestStatus\[l\].state != "ERROR" && accessRequestStatus\[l\].state != "NOT\_ALL\_ITEMS\_PROVISIONED") && accessRequestStatus\[l\].state != "PROVISIONING\_FAILED") > [!NOTE] > > Be aware that modifying the script will require manual updates for this change after each upgrade. ## Issues post upgrade, check and fix skipped files during upgrade Resolving conflicts during a ServiceNow upgrade is needed to ensure the upgraded instance functions correctly and as intended, preserving necessary customizations while adopting the new platform features and fixes. Conflicts arise when customization in your instance conflicts with the new, out-of-the-box (OOTB) version by SailPoint App. It skips these records and differences need to be reconciled by the administrator. SailPoint suggests reverting customizations to the base system to take advantage of new features and then re-applying your customizations accordingly. The following steps will check for conflicts and restore to the OOTB version. > [!NOTE] > > Related customizations will be lost and re-applied as necessary post these steps. 1. Change the ServiceNow scope to **SailPoint IdentityNow for Service Catalog**. 2. Go to **System Diagnostics \> Upgrades History** and apply the filter with `to_version=x_sap_intidn` > **Screenshot** > > [![Skipped Files Upgrade]()]() 3. Open the skipped records to review them. Select single or multiple records and then **Revert to Base System** to restore them to their original, out-of-the-box (OOB) state. > **Screenshot** > > [![Skipped Files Upgrade1]()]() ## Decoupling ServiceNow Approvals from Provisioning to Reduce Processing Delays > [!NOTE] > > **Screenshot** > > [![ServiceNow Catalog]()]() **Issue:** During multi-level approval in the ServiceNow catalog workflow (`SP_SPNT_SNOW_INT_CreateSailpointAccessRequest`), the last-level approval step was taking 20+ seconds. This occurred because the `createAccessRequest` API call was synchronously blocking the approval acknowledgement until AD provisioning (including IQService operations) completed. **Resolution:** Add a 1-second Timer step in the workflow to decouple the approval acknowledgement from provisioning execution. This block sits between the SailPoint access request creation and the Check LCM Enable in IIQ decision step. Adding the 1-second timer reduces approval response time from 20+ seconds to 3-5 seconds by preventing the provisioning process from holding the approval step. ## Access request checkout fails with a CartException **Issue:** ServiceNow administrators can submit SailPoint access requests. Other users cannot. The request stays in the cart, and ServiceNow returns the following error: `com.glideapp.servicecatalog.exceptions.CartException: Your cart has item(s) no longer available. Please remove SailPoint Access Request - Service Catalog from cart to continue with the checkout.` The application may also log `ISC0004 or Method failed to complete -submitRequest().` **Resolution:** Open the SailPoint Access Request \> Service Catalog \> catalog item and review Not Available For. Remove user criteria that include the `snc_internal` role. ServiceNow assigns that role to internal users, so listing it there blocks checkout for those users. Administrators can still submit requests because they bypass catalog user criteria. [Additional FAQs and Troubleshooting]() # Upgrading Architecture of every new feature is planned in such a way that existing features work as-is. SailPoint suggests that you always have the latest version, however, upgrading is not mandatory unless called out. Versions can be skipped and can be upgraded to the latest version without going through each individual upgrade. > [!IMPORTANT] > > SailPoint's ServiceNow Service Catalog for Identity Now relies on APl's published by SailPoint for data exchange. SailPoint is sunsetting the SailPoint legacy API gateway (Cloud Commander) and V2 APIs. Consequently, all versions of ServiceNow Catalog v3.0 and earlier are being deprecated. > > To address this, we have launched SailPoint ServiceNow Catalog Version 3.1. It is imperative that all customers upgrade to Version 3.1 before June 28, 2024, regardless of any previous information in the SailPoint support calendar. While there won't be a change in setup required by admins, we recommend exercising caution during the upgrade process to ensure a successful transition. > > Key Dates: > > - End of support for versions V3.0 and earlier: March 31st, 2024 > - Mandatory Upgrade for business continuity: June 28th, 2024 > [!IMPORTANT] > > ServiceNow admins must check for skipped items during each upgrade. As with other ServiceNow version upgrades, any object that has been customized (updated after application installation) on your instance for the SailPoint app will also need attention. A customized object is not overwritten by a new component during the upgrade, and is treated as a skipped change. In such cases, each of the entries must be reviewed and appropriate action taken. ## Reviewing Upgrade Information Use the following pages to review the information relevant to your upgrade: - [SailPoint API links]() lists the endpoint links for each supported application version. - [Version Upgrade Considerations]() covers versions 2.3.27 through 5.4. # Identity Security Cloud Links The Service Catalog app heavily relies on APIs to exchange communication with SailPoint. These APIs will change based on the version that is installed. During installation, this data gets filled in automatically via Demo Data. If the option is not selected during an upgrade, you must perform the following steps to manually enter the data into the table. 1. In the app, go to **Fulfiller View \> Navigation \> ISC Links** shortcut. 2. Update the table manually as per the upgrade version. 3. **Save** the changes. ## Version 5.4 The following table lists the 47 required endpoint links. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. > [!NOTE] > > `getSourceList` and `getAccessRequestStatus`s APIs have been discontinued and can be ignored. Customers upgrading from a version before 5.2 may still see them listed. | Serial Number | Action | Link | | --- | --- | --- | | 1 | accessRequestStatus | /v2025/access-request-status | | 2 | approveAccessRequest | /v2025/access-request-approvals/%approvalId%/approve | | 3 | auth | /oauth/token | | 4 | generic-approvals | /v2025/generic-approvals | | 5 | genericSearch | /v2025/search | | 6 | getAccessProfileApprovalDetails | /v2025/access-profiles/%id% | | 7 | getAccessProfileDetails | /v2025/access-profiles | | 8 | getAccessRequestConfig | /v2025/access-request-config | | 9 | getAccessRequestStatus | /v2025/access-request-administration | | 10 | getAccountActivities | /v2025/account-activities | | 11 | getAccountActivity | /v2025/account-activities/%id% | | 12 | getAccountActivity | /v2025/account-activities/%id% | | 13 | getAllGovernanceGroups | /v2025/workgroups | | 14 | getApplicationList | /v2025/source-apps/assigned | | 15 | getAvailableForRequestUsers | /v2025/requestable-objects/%requestableObjectId%/requestable-for-identities | | 16 | getCertificationAccessReviewItems | /v2025/certifications/%certificationID%/access-review-items | | 17 | getCertificationDecisionSummary | /v2025/certifications/%certificationID%/decision-summary | | 18 | getCertificationIdentityList | /v2025/certifications/%certificationID%/identity-summaries | | 19 | getCertificationRecommendations | /v2025/recommendations/request | | 20 | getCertificationReviewers | /v2025/certifications/%certificationID%/reviewers | | 21 | getCertifications | /v2025/certifications?reviewer-identity=me | | 22 | getEntitlementConfig | /v2025/entitlements/%entitlementId%/entitlement-request-config | | 23 | getEntitlementDetails | /v2025/entitlements/%id% | | 24 | getGovernanceGroupMembersById | /v2025/workgroups/%groupId%/members | | 25 | getIdentity | /v2025/public-identities | | 26 | getMultipleAccounts | /v2025/access-requests/accounts-selection | | 27 | getOrgInfo | /v2025/org-config | | 28 | getRequestableObjectList | /v2025/requestable-objects | | 29 | getRequestRecommendations | /v2025/ai-access-request-recommendations | | 30 | getRevocableObjects | /v2025/revocable-objects | | 31 | getRoleAssignmentTargets | /v2025/identities | | 32 | getRoleDetails | /v2025/roles/%id% | | 33 | getSoDDetails | /v2025/sod-policies | | 34 | getSources | /v2025/sources | | 35 | getTenantInfo | /v2025/tenant | | 36 | ignoreRequestRecommendation | /v2025/ai-access-request-recommendations/ignored-items | | 37 | pending-access-request-approvals | /v2025/access-request-approvals/pending | | 38 | postCancelRequest | /v2025/access-requests/cancel | | 39 | postSodViolations | /v2025/sod-violations/predict | | 40 | rejectAccessRequest | /v2025/access-request-approvals/%approvalId%/reject | | 41 | searchAccessEntitiesCombined | /v2025/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | 42 | searchAccessProfiles | /v2025/search/accessprofiles | | 43 | searchEntitlements | /v2025/search/entitlements | | 44 | searchRoles | /v2025/search/roles | | 45 | signOffCertificationDecisions | /v2025/certifications/%certificationID%/sign-off | | 46 | submitCertificationItemDecision | /v2025/certifications/%certificationID%/decide | | 47 | submitRequest | /v2025/access-requests | ## Version 5.2 The following table lists the 42 required endpoint links. Ensure that all the links are available in the application under the Identity Security Cloud Links table. > [!NOTE] > > `getSourceList`and `getAccessRequestStatu`s APIs have been discontinued and can be ignored. Customers upgrading from a version before 5.2 may still see them listed. | Serial Number | Action | Link | | --- | --- | --- | | 1 | accessRequestStatus | /v2025/access-request-status | | 2 | getSources | /v2025/sources | | 3 | getRequestableObjectList | /v2025/requestable-objects | | 4 | getCertificationDecisionSummary | /v2025/certifications/%certificationID%/decision-summary | | 5 | getCertificationIdentityList | /v2025/certifications/%certificationID%/identity-summaries | | 6 | getAccountActivity | /v2025/account-activities/%id% | | 7 | getAccessProfileDetails | /v2025/access-profiles | | 8 | postCancelRequest | /v2025/access-requests/cancel | | 9 | getEntitlementConfig | /v2025/entitlements/%entitlementId%/entitlement-request-config | | 10 | rejectAccessRequest | /v2025/access-request-approvals/%approvalId%/reject | | 11 | getAccountActivity | /v2025/account-activities/%id% | | 12 | getOrgInfo | /v2025/org-config | | 13 | pending-access-request-approvals | /v2025/access-request-approvals/pending | | 14 | getTenantInfo | /v2025/tenant | | 15 | getCertifications | /v2025/certifications?reviewer-identity=me | | 16 | approveAccessRequest | /v2025/access-request-approvals/%approvalId%/approve | | 17 | getAvailableForRequestUsers | /v2025/requestable-objects/%requestableObjectId%/requestable-for-identities | | 18 | genericSearch | /v2025/search | | 19 | searchEntitlements | /v2025/search/entitlements | | 20 | getApplicationList | /v2025/source-apps/assigned | | 21 | getAllGovernanceGroups | /v2025/workgroups | | 22 | submitRequest | /v2025/access-requests | | 23 | getGovernanceGroupMembersById | /v2025/workgroups/%groupId%/members | | 24 | searchAccessProfiles | /v2025/search/accessprofiles | | 25 | getAccountActivities | /v2025/account-activities | | 26 | submitCertificationItemDecision | /v2025/certifications/%certificationID%/decide | | 27 | searchRoles | /v2025/search/roles | | 28 | getRequestRecommendations | /v2025/ai-access-request-recommendations | | 29 | getSoDDetails | /v2025/sod-policies | | 30 | searchAccessEntitiesCombined | /v2025/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | 31 | getCertificationRecommendations | /v2025/recommendations/request | | 32 | getCertificationAccessReviewItems | /v2025/certifications/%certificationID%/access-review-items | | 33 | ignoreRequestRecommendation | /v2025/ai-access-request-recommendations/ignored-items | | 34 | getMultipleAccounts | /v2025/access-requests/accounts-selection | | 35 | getRoleAssignmentTargets | /v2025/identities | | 36 | postSodViolations | /v2025/sod-violations/predict | | 37 | getIdentity | /v2025/public-identities | | 38 | signOffCertificationDecisions | /v2025/certifications/%certificationID%/sign-off | | 39 | getCertificationReviewers | /v2025/certifications/%certificationID%/reviewers | | 40 | getAccessRequestConfig | /v2025/access-request-config | | 41 | getRevocableObjects | /v2025/revocable-objects | | 42 | auth | /oauth/token | ## Version 5.1 The following table lists the 41 required endpoint links for v5.1. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. | Serial Number | Action | Link | | --- | --- | --- | | 1 | approveAccessRequest | /v3/access-request-approvals/%approvalId%/approve | | 2 | auth | /oauth/token | | 3 | genericSearch | /v3/search | | 4 | getAccessProfileDetails | /v3/access-profiles | | 5 | getAccessRequestConfig | /v3/access-request-config | | 6 | getAccessRequestStatus | /v3/access-request-status | | 7 | getAccountActivities | /v3/account-activities | | 8 | getAccountActivity | /v3/account-activities/%id% | | 9 | getAllGovernanceGroups | /beta/workgroups | | 10 | getApplicationList | /v2024/source-apps/assigned | | 11 | getAvailableForRequestUsers | /v3/requestable-objects/%requestableObjectId%/requestable-for-identities | | 12 | getCertificationAccessReviewItems | /v3/certifications/%certificationID%/access-review-items | | 13 | getCertificationDecisionSummary | /v3/certifications/%certificationID%/decision-summary | | 14 | getCertificationIdentityList | /v3/certifications/%certificationID%/identity-summaries | | 15 | getCertificationRecommendations | /beta/recommendations/request | | 16 | getCertificationReviewers | /v3/certifications/%certificationID%/reviewers | | 17 | getCertifications | /v3/certifications?reviewer-identity=me | | 18 | getEntitlementConfig | /beta/entitlements/%entitlementId%/entitlement-request-config | | 19 | getGovernanceGroupMembersById | /beta/workgroups/%groupId%/members | | 20 | getIdentity | /v3/public-identities | | 21 | getMultipleAccounts | /v3/access-requests/accounts-selection | | 22 | getOrgInfo | /beta/org-config | | 23 | getRequestableObjectList | /v3/requestable-objects/ | | 24 | getRequestRecommendations | /beta/ai-access-request-recommendations | | 25 | getRevocableObjects | /v2025/revocable-objects | | 26 | getRoleAssignmentTargets | /beta/identities | | 27 | getSoDDetails | /v3/sod-policies | | 28 | getSourceList | /v3/sources | | 29 | getTenantInfo | /beta/tenant | | 30 | ignoreRequestRecommendation | /beta/ai-access-request-recommendations/ignored-items | | 31 | pending-access-request-approvals | /v3/access-request-approvals/pending | | 32 | postCancelRequest | /v3/access-requests/cancel | | 33 | postSodViolations | /v3/sod-violations/predict | | 34 | rejectAccessRequest | /v3/access-request-approvals/%approvalId%/reject | | 35 | searchAccessEntitiesCombined | /v3/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | 36 | searchAccessProfiles | /v3/search/accessprofiles | | 37 | searchEntitlements | /v3/search/entitlements | | 38 | searchRoles | /v3/search/roles | | 39 | signOffCertificationDecisions | /v3/certifications/%certificationID%/sign-off | | 40 | submitCertificationItemDecision | /v3/certifications/%certificationID%/decide | | 41 | submitRequest | /v3/access-requests | ## Version 5.0 The following table lists the 41 required endpoint links for v5.0. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. | Serial Number | Action | Link | | --- | --- | --- | | 1 | approveAccessRequest | /v3/access-request-approvals/%approvalId%/approve | | 2 | auth | /oauth/token | | 3 | genericSearch | /v3/search | | 4 | getAccessProfileDetails | /v3/access-profiles | | 5 | getAccessRequestConfig | /v3/access-request-config | | 6 | getAccessRequestStatus | /v3/access-request-status | | 7 | getAccountActivities | /v3/account-activities | | 8 | getAccountActivity | /v3/account-activities/%id% | | 9 | getAllGovernanceGroups | /beta/workgroups | | 10 | getApplicationList | /v2024/source-apps/assigned | | 11 | getAvailableForRequestUsers | /v3/requestable-objects/%requestableObjectId%/requestable-for-identities | | 12 | getCertificationAccessReviewItems | /v3/certifications/%certificationID%/access-review-items | | 13 | getCertificationDecisionSummary | /v3/certifications/%certificationID%/decision-summary | | 14 | getCertificationIdentityList | /v3/certifications/%certificationID%/identity-summaries | | 15 | getCertificationRecommendations | /beta/recommendations/request | | 16 | getCertificationReviewers | /v3/certifications/%certificationID%/reviewers | | 17 | getCertifications | /v3/certifications?reviewer-identity=me | | 18 | getEntitlementConfig | /beta/entitlements/%entitlementId%/entitlement-request-config | | 19 | getGovernanceGroupMembersById | /beta/workgroups/%groupId%/members | | 20 | getIdentity | /v3/public-identities | | 21 | getMultipleAccounts | /v3/access-requests/accounts-selection | | 22 | getOrgInfo | /beta/org-config | | 23 | getRequestableObjectList | /v3/requestable-objects/ | | 24 | getRequestRecommendations | /beta/ai-access-request-recommendations | | 25 | getRevocableObjects | /v2025/revocable-objects | | 26 | getRoleAssignmentTargets | /beta/identities | | 27 | getSoDDetails | /v3/sod-policies | | 28 | getSourceList | /v3/sources | | 29 | getTenantInfo | /beta/tenant | | 30 | ignoreRequestRecommendation | /beta/ai-access-request-recommendations/ignored-items | | 31 | pending-access-request-approvals | /v3/access-request-approvals/pending | | 32 | postCancelRequest | /v3/access-requests/cancel | | 33 | postSodViolations | /v3/sod-violations/predict | | 34 | rejectAccessRequest | /v3/access-request-approvals/%approvalId%/reject | | 35 | searchAccessEntitiesCombined | /v3/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | 36 | searchAccessProfiles | /v3/search/accessprofiles | | 37 | searchEntitlements | /v3/search/entitlements | | 38 | searchRoles | /v3/search/roles | | 39 | signOffCertificationDecisions | /v3/certifications/%certificationID%/sign-off | | 40 | submitCertificationItemDecision | /v3/certifications/%certificationID%/decide | | 41 | submitRequest | /v3/access-requests | ## Version 4.0 The following table lists the 27 required endpoint links and one unused link (getIdentityDetails) to be used with v4.0. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. | Action | Link | | --- | --- | | approveAccessRequest | /v3/access-request-approvals/%approvalId%/approve | | auth | /oauth/token | | genericSearch | /v3/search | | getAccessProfileDetails | /v3/access-profiles | | getAccessRequestConfig | /v3/access-request-config | | getAccessRequestStatus | /v3/access-request-status | | getAccountActivities | /v3/account-activities | | getAllGovernanceGroups | /beta/workgroups | | getAvailableForRequestUsers | /v3/requestable-objects/%requestableObjectId%/requestable-for-identities | | getEntitlementConfig | /beta/entitlements/%entitlementId%/entitlement-request-config | | getGovernanceGroupMembersById | /beta/workgroups/%groupId%/members | | getIdentity | /v3/public-identities | | getIdentityDetails | empty | | getOrgInfo | /beta/org-config | | getRequestRecommendations | /beta/ai-access-request-recommendations | | getSoDDetails | /v3/sod-policies | | getSourceList | /v3/sources | | getTenantInfo | /beta/tenant | | ignoreRequestRecommendation | /beta/ai-access-request-recommendations/ignored-items | | pending-access-request-approvals | /v3/access-request-approvals/pending | | postCancelRequest | /v3/access-requests/cancel | | postSodViolations | /v3/sod-violations/predict | | rejectAccessRequest | /v3/access-request-approvals/%approvalId%/reject | | searchAccessEntitiesCombined | /v3/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | searchAccessProfiles | /v3/search/accessprofiles | | searchEntitlements | /v3/search/entitlements | | searchRoles | /v3/search/roles | | submitRequest | /v3/access-requests | ## Version 3.2 The following table lists the 27 required endpoint links and one unused link (getIdentityDetails) to be used with v3.2. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. | Action | Link | | --- | --- | | approveAccessRequest | /v3/access-request-approvals/%approvalId%/approve | | auth | /oauth/token | | genericSearch | /v3/search | | getAccessProfileDetails | /v3/access-profiles | | getAccessRequestConfig | /v3/access-request-config | | getAccessRequestStatus | /v3/access-request-status | | getAccountActivities | /v3/account-activities | | getAllGovernanceGroups | /beta/workgroups | | getAvailableForRequestUsers | /v3/requestable-objects/%requestableObjectId%/requestable-for-identities | | getEntitlementConfig | /beta/entitlements/%entitlementId%/entitlement-request-config | | getGovernanceGroupMembersById | /beta/workgroups/%groupId%/members | | getIdentity | /v3/public-identities | | getIdentityDetails | empty | | getOrgInfo | /beta/org-config | | getRequestRecommendations | /beta/ai-access-request-recommendations | | getSoDDetails | /v3/sod-policies | | getSourceList | /v3/sources | | getTenantInfo | /beta/tenant | | ignoreRequestRecommendation | /beta/ai-access-request-recommendations/ignored-items | | pending-access-request-approvals | /v3/access-request-approvals/pending | | postCancelRequest | /v3/access-requests/cancel | | postSodViolations | /v3/sod-violations/predict | | rejectAccessRequest | /v3/access-request-approvals/%approvalId%/reject | | searchAccessEntitiesCombined | /v3/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | searchAccessProfiles | /v3/search/accessprofiles | | searchEntitlements | /v3/search/entitlements | | searchRoles | /v3/search/roles | | submitRequest | /v3/access-requests | ## Version 3.1 The following table lists the 23 required endpoint links and one unused link (getIdentityDetails) to be used with v3.1. Ensure that all of the links below are available in the application under the **Identity Security Cloud Links** table. | Action | Link | | --- | --- | | approveAccessRequest | /v3/access-request-approvals/%approvalId%/approve | | auth | /oauth/token | | genericSearch | /v3/search | | getAccessProfileDetails | /v3/access-profiles | | getAccessRequestConfig | /v3/access-request-config | | getAccessRequestStatus | /v3/access-request-status | | getAccountActivities | /v3/account-activities | | getAllGovernanceGroups | /beta/workgroups | | getAvailableForRequestUsers | /v3/requestable-objects/%requestableObjectId%/requestable-for-identities | | getEntitlementConfig | /beta/entitlements/%entitlementId%/entitlement-request-config | | getGovernanceGroupMembersById | /beta/workgroups/%groupId%/members | | getIdentity | /v3/public-identities | | getIdentityDetails | empty | | getOrgInfo | /beta/org-config | | getRequestRecommendations | /beta/ai-access-request-recommendations | | getSourceList | /v3/sources | | pending-access-request-approvals | /v3/access-request-approvals/pending | | postSodViolations | /v3/sod-violations/predict | | rejectAccessRequest | /v3/access-request-approvals/%approvalId%/reject | | searchAccessEntitiesCombined | /v3/search?offset=%nuberOfRecords%&limit=%resultsLimit%&count=true | | searchAccessProfiles | /v3/search/accessprofiles | | searchEntitlements | /v3/search/entitlements | | searchRoles | /v3/search/roles | | submitRequest | /v3/access-requests | # Version Upgrade Considerations Review the upgrade considerations for ServiceNow Service Catalog versions 2.3.27 through 5.4. ## Upgrading to V5.4 This section lists points to consider when you upgrade from any previous version to v5.4, or upgrade through v5.4. > [!NOTE] > > This page does not capture product changes from other versions. > [!IMPORTANT] > > v5.4 changes how SailPoint and ServiceNow communicate, and it includes mandatory connection changes. Follow all prerequisites and upgrade steps carefully. This release delivers a significant architectural change. It provides the following benefits: - RITM status updates are faster when approvals complete or provisioning finishes. - Workflows are less likely to stall in timer windows when SailPoint response times vary. - ServiceNow makes fewer REST API polling calls to SailPoint. - Search returns more precise results when users need an exact multi-word phrase. SailPoint recommends that admins review the release notes and update their configuration to suit their business needs. ### Updating Identity Security Cloud Links Update the Identity Security Cloud Links table to reflect the latest endpoints. For more information, refer to [Version 5.4](). ### Configuring ISC Event Triggers v5.4 replaces timer-based polling with SailPoint event triggers for approval synchronization and access request status updates. Configure the required triggers before you use the app. For more information, refer to Configuring ISC Event Triggers. These triggers are available only to licensed ServiceNow Catalog customers. Workflows and the related code have changed. If you customized these objects, review them for conflicts.ISC Event Triggers require additional connection configuration. Refer to [Prerequisites]() for the new setup steps. ### ISC Backup Utility The ISC Backup Utility scheduled job reconciles missed events when ISC connectivity or event delivery fails. The job is set to run On Demand by default. For more information, refer to [Configuring the ISC Backup Utility](). ### ISC Event Processing Table Cleaner The ISC Event Processing table receives a high volume of events from SailPoint. SailPoint recommends that you activate the Data Management Policy to clean this table periodically. Set a retention period of seven days, or a period that matches your data management policy. For more information, refer to [Configuring the ISC Event Processing Table Cleaner](). ### Quoted Phrase Search in ISC Access Object Search The ISC Access Object Search widget query parser now treats text in double quotes as a single phrase token. Unquoted text keeps the existing match behavior. This applies to the Name, Description, and Additional Search filters when the operator is Contains ALL the keywords. Upgrade this widget and apply the widget options. For more information, refer to [SailPoint Widget Library](). ## Upgrading to V5.3 ### Optimised Authentication for Performance Improvement To provide greater runtime efficiency and reduce repeated OAuth token calls, a new **Application Registries Auth Provider Name for Service Account** parameter is now available on the Setup page. ServiceNow Administrator must create a third-party OAuth provider registry (configuring the client ID/secret, grant type, and token URL) and map it here to enable this from v5.3 onwards. This will not impact the upgrade for this release but will be mandated for releases starting 2027. hence, its suggested to implement with this release itself. For more information, refer to [Service Account Configuration](). ### Additional Approval Types Support This update expands approval routing options by introducing support for **Identity Security Cloud Primary Owner, Additional Owners,** and **All Owners** patterns. It clarifies owner resolution behavior by fetching owners from SailPoint and mapping them to local ServiceNow users. If no valid owner mapping is found, approvals fall back to the default approval group (for example, SailPoint Access Governance Group). It also notes naming updates and compatibility rules (for example, “All Owners” is mutually exclusive with certain other owner-based types). > [!NOTE] > > Upon upgrading, any existing configurations using the "Identity Security Cloud Owner" approval type will automatically be updated to "Identity Security Cloud Primary Owner." This update is seamless and does not affect the underlying functionality. For more information Refer to [Approval Flexibility](). This will not impact any other existing functionality during upgrade. ### Questionnaire and “Additional Info” Form Enhancements With the release of version 5.3, we've updated the behavior of the Review and Submit widget to better handle additional information validation. You can now configure the widget using two response modes: “ Mandatory Questions Only” and “Response Required Per Access”. This update replaces the existing widget behavior and includes refreshed instance options to improve the user experience during request submission. This will not impact the existing functionality during upgrade. For more information, refer to [SailPoint Widget Library.]() ### Additional Search in Access Object Search Widget With the release of version 5.3, we've enhanced the Access Search widget to support broader, tenant-specific search behaviour. This widget too has ability to search from any searchable objects of SailPoint, including meta-data and tags. The Additional Search Label and Additional Searchable Fields options are now available as widget instance options, allowing you to configure a comma-separated list of custom search fields. This removes the previous limitation of only searching predefined fields like name, description, owner, and application, greatly improving discoverability in large catalogs. This will not impact the existing functionality during upgrade. For more information, refer to [SailPoint Widget Library](). ### Re-Organized Setup Page With the release of version 5.3, the SailPoint Setup page has been redesigned and reorganized. As the application has grown, new configuration options have been added. To improve usability and make administration easier, settings are now logically grouped into distinct categories. For more information, refer to [Configuring Other Parameters](). > [!NOTE] > > Upgrading to v5.3 will not overwrite, reset, or delete your existing configurations. All parameters configured in v5.2 or earlier will automatically carry over to their new designated section. Since only the label has changed and the value remains the same, all parameters will automatically carry over to the new designated section. ## Upgrading to V5.2 This section lists points to be considered while upgrading from any previous version to v5.2 or upgrading through v5.2. > [!NOTE] > > This page does not capture changes to the product of other versions. ### Multi Accounts Enhanced Information To provide greater flexibility and for compatibility with previous version , a new Multi Account support enabled parameter is now available on the Setup page. You must enable this parameter if you are upgrading from v5.1 to v5.2 and want to use the Multi Account functionality. The default value is disabled. For more information Refer to [Configuring Multi Account](). ### New Instance Options for Access Object Section Widget New instance options are added for **ISC Access Object Selection** and **ISC Access Object Selection 2** - **Encoded Query for roles, access profiles, and entitlements under Remove Access** - This optional filters are applicable only on the Remove Access tab and These are searchable fields. This will not impact the upgrade. For more information Refer to [SailPoint Widget Library.]() - **Show Disabled access objects under Add Access** and **Show Disabled access objects under Remove Access** - The checkboxes to include or hide disabled roles and access profiles (not entitlements) in Add and Remove tab results. This will not impact the upgrade. For more information Refer to [SailPoint Widget Library.]() ### HTML Rendering in Access Object Selection Widgets The **Access Object Selection** widget now supports HTML markup in descriptions for Roles, Access Profiles, and Entitlements. The access object description displayed in the Access Object Selection widget now supports HTML markup. When HTML tags are present in the description, the system renders the content without escaping the tags, allowing the browser to display the intended formatting such as paragraph breaks, bold text, and lists.The description is shown as-is, exactly as configured in SailPoint, ensuring consistency of information across platforms. This enhancement applies to all three access types Roles, Access Profiles, and Entitlements improving readability and providing a clearer and more accurate representation of access details for users during access selection. This will not impact the upgrade. > [!NOTE] > > **Screenshot** > > [![important announcement]()]() > [!NOTE] > > **Screenshot** > > [![Copy of Access object in ServiceNow]()]() > [!NOTE] > > **Screenshot** > > [![Copy of Access Object in SailPoint Identity Security Cloud]()]() ### Widget Option to Hide "Remove Access" in ISC Access Type Widget The ServiceNow administrators can now control whether the "Remove Access" option is visible to end-users within the **Access Type** widget. This prevents accidental or unauthorised access removal requests directly from the widget. This will not impact the upgrade. For more information Refer to [SailPoint Widget Library.]() ### Migration of Existing APIs to V2025 APIs Now all the links available in the application under the “SailPoint Links” table are migrated to v2025 APIs. For more information Refer to [Version 5.2 Updated.]() ### Enhanced Search Support for Special Characters Previously, when users searched for access objects containing special characters, the system displayed an alert message “Search string with special characters may fetch incorrect results” and the results can be inaccurate. The search functionality has now been enhanced to fully support special characters, ensuring accurate results, and the alert message has been removed. This enhancement is available in both **Add Access** and **Remove Access** tabs, providing a smoother and more reliable search experience for users. This will not impact the upgrade. > [!NOTE] > > **Screenshot** > > [![Enhanced search functionality to support special characters]()]() ### Access Description Variable A new **Access Description** variable has been added to the SailPoint Access Request catalog. This field automatically pulls description from the access object to provide context during the request phase. This will not impact the upgrade. > [!NOTE] > > **Screenshot** > > [![Access Description]()]() ### Free Text Search for Add Access New filtering capabilities have been introduced for **ISC Request 2** and **SailPoint Record Producer 2**. Users can now use keywords to filter Requestable Entitlements Access Profiles and Dependent Roles. To upgrade from any previous version to v5.2 or upgrade through v5.2 “Select Filters” option is not present. > [!NOTE] > > This filtering logic is currently exclusive to the Add Access tab. ### Configure Search Tabs Using Instance Option With the release of version 5.2, we've made widget configuration more convenient. The List and order of Search results tab. Exact text separated by comma to be used.(For manage\_access page and Native search only) option is now directly available as an instance option for widgets. Prior to this version, this setting was located only on the Setup page. For more information Refer to [Configuring the Search Results Tab](). ## Upgrading to V5.1 This section lists points to be considered while upgrading from any previous version to v5.1 or upgrading through v5.1. > [!NOTE] > > This page does not capture changes to the product of other versions. ### Custom Questionnaire No changes are required if you don't plan to use this feature; The upgrade will not be impacted. Refer to corresponding pages on how to use this functionality. #### Search Filter Configuration The options you select in the ISC Access Object Search widget impact how your end users use the search. These selections help configure the search with what your users are familiar with. Refer to corresponding widget documentation on how to use this functionality. ##### MultiAccounts Enhanced Information Additional information is displayed if you use the MultiAccounts feature of SailPoint. No changes are required during the upgrade. ##### Certification Widget Has a Custom Pop-Up Additional information to help certifiers make a decision can be displayed in a custom pop-up. The information will be specific to the needs, and a provided a pop-up widget will be unlocked for making edits. By default, the pop-up does not display; The upgrade will not be impacted. Refer to corresponding widget documentation on how to use this functionality. ##### Ability to Accept Empty Approver Value from Script If there is a need to skip an approval step based on approval logic, the script won't force the send (to one or more users). No changes are required during the upgrade. To take advantage of this functionality use the ServiceNowScript during approval. ##### Custom Pop-Up Page and Push Metadata Along with Submit Additional information can be accepted while submitting a request for adding/revoking access. By default, the pop-up does not display; The upgrade will not be impacted. Refer to corresponding widget documentation on how to use this functionality. ##### Review and Submit Widget Alignment The widget interface is best coded for the most probable combinations to display the columns. If you want a different view of the displayed information you can make a copy of the widget and edit the HTML component. ##### Block Duplicate Requests Duplicate requests are blocked. A new request can't be submitted for a user if its identical to an existing request waiting to be processed. The same applies for a user with multiple accounts, respective of the source and account combination. ## Upgrading to V5.0 This section lists points to be considered while upgrading from any previous version to v5.0 or upgrading through v5.0. > [!NOTE] > > This page does not capture changes to the product of other versions. This release has multiple improvements and code fixes to v5.0 which had a significant architectural change. SailPoint recommends admins go through the release notes of this release and update the related setup as per business needs. ### ISC Certification Support The ServiceNow Certification Portal for Identity Security Cloud enables designated people to review users’ access to your enterprise systems and data. Certifiers determine whether the access is appropriate for those users or if access should be revoked. Certifiers will review certifications, approve or revoke access, and sign off on decisions This ServiceNow portal focuses only on SailPoint’s Certification Review Process. This works independently to the request process. OAUTH2 authentication is mandatory for this integration. Setup parameters for certification can be ignored if this process is not used in your implementation. Enabling this functionality in the ServiceNow instance requires you to follow these activities: - Ensure the [Identity Security Cloud Links]() now include the APIs related to Certification. - Refer to [Configuring Connection Parameters]() for Certification. - Configure the ISC Certification page or use the widgets related to Certification in your custom page. - Assign appropriate roles to access this page and functionality. > [!NOTE] > > Version 5.0 supports limited features of the Certification interface. Additional features will be added in upcoming releases. > > - Role Composition Certification Campaign is not supported. ### Multi Account Support > [!NOTE] > > With the multi-account feature, validation of existing access will no longer be performed. SailPoint is designed to correlate multiple accounts belonging to the same human to a single "identity." This is crucial for maintaining a unified view of a user's access across various systems, even if they have different accounts in the same application. SailPoint has recently added "Multi-Account Support" in the Access Request flow. With v5.0, similar functionality can be achieved through ServiceNow using this version of the Catalog App. This means that when a user has more than one account on a source, the requester is prompted to choose which specific account to provision access to. This applies to Roles and Entitlements as per the design of SailPoint. This also applies to access revocation from the appropriate account for roles. Ability to revoke for entitlements will be introduced in a future release. ## Upgrading to V4.1 This section lists points to be considered while upgrading from any previous version to v4.1 or upgrading through v4.1. > [!NOTE] > > This page does not capture changes to the product of other versions. This release has multiple improvements and code fixes to v4.0 which had a significant architectural change. SailPoint recommends admins go through the release notes of this release and update the related setup as per business needs. ### Improved Widget Options Additional widget options to the following widgets have been introduced. For more information, refer to [SailPoint Widget Library](). - The ability to further filter users in the **ISC User Selection** widget - The ability to further filter users in the **ISC User Selection 2** widget - Multiple widget options for **ISC Access Object Selection** including query filter - Multiple widget options for **ISC Access Object Selection 2** including query filter - The ability to select a default operator in the **ISC Access Object Search** widget - Multiple widget options for **Sunset Date** - Multiple widget options for **ISC Review And Submit** - Multiple widget options for **ISC Review And Submit 2** ### Search by Applications A dropdown list of applications has been introduced in **Access Object Search**. End users will have the ability to select the active applications. The related access profiles, roles and/or entitlements will be listed and can be selected to request access. ### Ability to Add Attachments SailPoint Record Producer can be configured to add attachments. This feature is not available for request pages. ## Upgrading to V4.0 This section lists points to be considered while upgrading from any previous version to v4.0 or upgrading through v4.0. > [!NOTE] > > This page does not capture changes to the product of other versions. This release marks a significant architectural change. While the current page, Manage\_Access, has minimal changes, two new options have been added to configure access requests. SailPoint recommends transitioning to the new architecture, using either the page SailPoint\_Request or the record producer. Manage\_Access will receive minimal upgrades in upcoming releases. SailPoint requests that you read through the release notes and update the related setup as per your business needs. To watch a video of the v4.0 demo, refer to [ServiceNow Catalog for Identity Security Cloud 4.0: New architecture demo](). ### References to IDN (IdentityNow) Changed to ISC (Identity Security Cloud) All references to IdentityNow (IDN) are now updated to Identity Security Cloud (ISC) including the application name. This change should not impact your usage unless there are hard-coded references or specific documentation requirements. ### Manage\_Access Page - Additional Labels for Internationalization Additional labels have been added to the Manage\_ Access page for Internationalization. For detailed information on the process, refer to [Language Internationalization](). ### Approval Flexibility - Additional Approval Types The capability to define the following approval types, in addition to the existing ones, enhances flexibility in creating suitable approval workflows. For more information, refer to [Approval Flexibility](). - ISC Source Owner - ISC App Owner ### SetUp Property - Native Search Redirect Page ID (Example: Manage\_access) Now, with the availability of multiple pages for access requests, you can leverage this feature to direct users to the submission page when using native search. For more information on configuring native search, refer to [Configuring Native Search](). The target page must either be the Manage\_Access page, or the new page must include the ISC Access Object Selection widget. ### Additional States Handled in Access Request Status The Access Request Status now encompasses additional states based on SailPoint logic. This enhancement addresses provisioning failure errors caused by missing statuses. If you have made any adjustments to this logic, you must ensure the code is integrated accordingly. ### Ability to Relate Entitlements to Roles For Roles, selecting the option for **Details** will show related Entitlements in addition to Access profiles. This functionality is available only in the widgets. ### Setup Property Determines Which Logs to Print Widgetized architecture uses this property. The default is warn, and the additional options are debug, info, and error. All logs are printed based on this setting. For more information, refer to the [SailPoint Widget Library](). ### Widgetized Architecture New architecture has been introduced to provide flexibility to configure and customize the behavior of the app. Widgets will be released and you will have the choice to select and customize them as per your business needs. Additionally, with this change customers can let their end users request access via Record producer. For more information, refer to the [SailPoint Widget Library](). ## Upgrading to V3.2 This section lists points to be considered while upgrading from any previous version to v3.2 or upgrading through v3.2. > [!NOTE] > > This page does not capture changes to the product of other versions. Version 3.2 ### Skip User Selection Page for Users Who Can't Request for Others A field named **Skip user selection screen for users who can request access for self only** has been introduced on the setup page with a default value of `Yes`. This option enables skipping the user selection page for users who only need to select access for themselves. If it becomes necessary to make user selection mandatory again, you can change the value to `No`. ### Ability to Use Global Search for SailPoint Searchable Data For more information on the configuration and limitations, refer to [Configuring Native Search](). ### Ability to Use OAuth2 for Approval Flexibility OAuth2 connections can also configure approval flexibility. For more information, refer to [Approval Flexibility](). ### Recommendations Tab Visibility A field named **Show Recommendations, applicable only if required license available?** has been introduced on the setup page. Selecting `Yes` will display the recommendations tab, which is applicable only if the required licenses are available. ### Support for Employee Service Center You can now set up SailPoint’s `Manage Access` page from within the Employee Service Center to allow for easy access. For more information, refer to [Employee Service Center Portal Configuration](). ### Linking Service Desk Tickets with Service Catalog Tickets If you have both the `SailPoint Identity Security Cloud for Service Catalog` and the `SailPoint for Service Desk` store applications installed on the same ServiceNow instance, you can now link the tickets created by both these applications. For more information, refer to [Linking with the SailPoint for Service Desk Application](). ### Additional SoD Policy Violation Details in Requests If Separation of Duties policy checks are set to `Allow: Soft Submission` additional policy violation details will be added in the requested items to help approvers make better informed decisions. ## Upgrading to V3.1 This section lists points to be considered while upgrading from any previous version to v3.1 or upgrading through v3.1. > [!IMPORTANT] > > A mandatory upgrade by all customers is required before the end of Q2’24 irrespective of the previously published support calendar. Some of the API’s used by the catalog app are being decommissioned, therefore, present apps must be upgraded. All presently installed versions (including 3.0) must be upgraded, otherwise the app will not be able to perform its primary functionalities. > [!NOTE] > > This page does not capture changes to the product of other versions. There is no change in setup required by admins for this release, however, caution needs to be maintained by keeping a close watch on skipped items during the upgrade. The following are the changes in this release: Version 3.1 - Upgraded API to comply with APIs being decommissioned in Q2’24. - Catalog App now supports the ability to search and request using the related Entitlement Owner. - Review existing access search query improvements related to special characters. Admins need to validate that each new value has been populated in the [Identity Security Cloud Links]() column for the following: | Action | Previous Value | New Value | | --- | --- | --- | | getAllGovernanceGroups | /v2/workgroups | /beta/workgroups | | getGovernanceGroupMembersById | /v2/workgroups/%groupId%/members | /beta/workgroups/%groupId%/members | | getAccessProfileDetails | /v2/access-profiles | /v3/access-profiles | | getOrgInfo | /cc/api/org/get | /beta/org-config | | getSourceList | /beta/sources | /v3/sources | | getAccessRequestStatus | /beta/access-request-status | /v3/access-request-status | ### Access Items Search with Entitlement Owner This feature provides the ability to search and request for entitlements by Owners. Previously, the Owner value in the entitlements tab was blank, however, SailPoint has extended the feature available in SailPoint. > [!NOTE] > > **Screenshot** > > [![ent]()]() There is an existing system property that is no longer used and is removed from the application repository. It will not be added with a fresh new installation of the application. However, for existing customers upgrading from an older version to a newer version, this property is not automatically deleted. Although the property is not used in any of the code, it will still appear in the setup page. > [!NOTE] > > **Screenshot** > > [![Copy of WF Editor6]()]() To keep upgraded applications in sync with latest changes, you must manually delete the property by performing the following steps. 1. Use the URL to navigate to the property, replacing `instance_name` with your instance name. [https://instance\_name.service-now.com/sys\_properties\_list.do?sysparm\_query=name%3Dx\_sap\_intidn.x\_sp\_spnt\_snow\_int.enable\_request\_for\_entitlements]() 2. Select the property shown in the list layout. > **Screenshot** > > [![Copy of WF Editor7]()]() 3. In the drop-down from related action link, select the **Delete** option. > **Screenshot** > > [![Copy of WF Editor8]()]() ## Upgrading to V3.0 This section lists points to be considered while upgrading from any previous version to v3.0 or upgrading through v3.0. > [!NOTE] > > This page does not capture changes to the product of other versions. Admins must set the following fields in the **Setup** page. - Comments Configuration, Label: **Default comments for requested items. Keep it blank to impose comment configuration of IDN**. For more information, refer to [Configuring the Comments](). - Ability to Hide/Re-Order Search tabs, Label: **List and order of Search results tab. Exact text separated by comma to be used. Refer to documentation for examples**. For more information, refer to [Configuring the Search Results Tab](). - Default/Generic Approval Definitions, Label: **Generic Approval Definition Enabled (Applicable only if Configurable Approvals selected for Approval Flow)**. For more information, refer to [Generic Approval Definition](). - Auto Approval settings are read from Identity Security Cloud Manager and Identity Security Cloud Owner rule types. For more information, refer to [Approval Flexibility](). - Expiration/Sunset date configuration, Label: **Is Sunset Date Mandatory for Access Requests?**. For more information, refer to [Configuring the Sunset Date](). There is an existing system property that is no longer used and is removed from the application repository. It will not be added with a fresh new installation of the application. However, for existing customers upgrading from an older version to a newer version, this property is not automatically deleted. Although the property is not used in any of the code, it will still appear in the setup page. > [!NOTE] > > **Screenshot** > > [![Copy of WF Editor6]()]() To keep upgraded applications in sync with latest changes, you must manually delete the property by performing the following steps. 1. Use the URL to navigate to the property, replacing `instance_name` with your instance name. [https://instance\_name.service-now.com/sys\_properties\_list.do?sysparm\_query=name%3Dx\_sap\_intidn.x\_sp\_spnt\_snow\_int.enable\_request\_for\_entitlements]() 2. Select the property shown in the list layout. > **Screenshot** > > [![Copy of WF Editor7]()]() 3. In the drop-down from related action link, select the **Delete** option. > **Screenshot** > > [![Copy of WF Editor8]()]() ## Upgrading to V2.3.30 This section lists points to be considered while upgrading from any previous version to v2.3.30 or upgrading through v2.3.30 > [!NOTE] > > This page does not capture changes to the product of other versions. - Admins must set the following fields in the **Setup** page: - Configuration of page headers: - To enable the customizable text box, select `Yes` on the **Show Header text box**. For more information, refer to [Configuring Page Headers](). - Admins and members of the change management team need to train the end users on the updates related to: - The ability to raise a request to review entitlement access. Users were not able to request this at the entitlement level in previous versions. - The ability to configure your pages for internationalization. For more information, refer to [Language Internationalization](). ## Upgrading to V2.3.28 or V2.3.29 This section lists points to be considered while upgrading from any previous version to v2.3.28 or upgrading through v2.3.28 and v2.3.29. > [!NOTE] > > This page does not capture changes to the product of other versions. - Admins must set the following fields in the **Setup** page: - Label the Approval Flow. From the dropdown, select **Configurable Approvals** to add it. For more information on the configuration, refer to [Approval Flexibility](). This setting affects the previously configured label for **Disable ServiceNow Manager Approval**. The old value cannot be carried forward to the new label, so you must plan to configure it accordingly. ## Upgrading to V2.3.27 This section lists points to be considered while upgrading from any previous version to v2.3.27 or upgrading through v2.3.27. > [!NOTE] > > This page does not capture changes to the product of other versions. - Admins and members of the change management team need to train the end users on the updates related to: - New and improved search fields - The tabbed version of search results - Admins must set the following fields in the **Setup** page: - Label the enable requests for entitlements - The default is `false` to maintain compatibility with the previous version. - Set it to `true` if your organization intends to allow access requests for entitlements. - Label displays non-requestable access objects. - Controls whether to show or hide the non-revocable access objects on the **Review Existing Access** tab. - The default is set to `No`. - Refer to [Integrating Identity Security Cloud with ServiceNow Service Catalog]() for more information. # Using the ServiceNow Portal Integration for Identity Security Cloud ## Request and Review Access After your System Administrator has successfully integrated SailPoint with the ServiceNow Portal, you’ll be able to use it to generate access requests. > [!NOTE] > > - Duplicate requests are blocked. A new request can't be submitted for a user if its identical to an existing request waiting to be processed. The same applies for a user with multiple accounts, respective of the source and account combination. > - Users who are managers can submit requests to revoke access for their directly managed employees, however, they cannot revoke access for themselves. To request access profiles and roles for users: 1. Sign in to the ServiceNow Portal with your credentials. > **Screenshot** > > [![Copy of SN Login]()]() 2. Select **Manage Access** to access the application. Depending on the type of authorization used for your integration, you may receive a dialog to sign into SailPoint before continuing. ```text ??? note "Screenshot" ![sign into IDN](img/sign_into_idn.png) !!! note This is the default configuration. Your organization may use a different method to access the app from within your ServiceNow Service Portal. ``` ### User Details 1. In stage **1 - User Details** you can search for a specific user by entering their name in the search field. You can also use the controls below the set of cards to page through the users. [![Copy of SN User Details1]()]() 1. To select a user, click the top section of their "card" that contains a check mark and their name, and then select **Next**. [![Copy of SN User Details2]()]() Up to 10 users can be selected. The initials of each selected user are displayed at the top of the widget. Hover over a user's initials on the widget to reveal their full name on all pages. User Retrieval and Synchronization: Users are retrieved from the users table in ServiceNow. As a prerequisite, SailPoint requires that user data be synchronized between ServiceNow and SailPoint. If a user mismatch is detected, a validation process occurs, and an error message (e.g., "User Mismatch") is displayed. This validation occurs: - The system allows navigation to the next screen. - The user that does not exist on SailPoint remains in the selection. - Upon submission, the system displays: “You cannot submit an access request for a user who does not exist.” Expected Behavior / Functionality: - Requests for users that exist on SailPoint are processed correctly. - Submissions for users that do not exist on SailPoint are blocked. - This behavior is consistent with product design and expected functionality. [![Combo Users]()]() ### Select Access 1. In stage **2 - Select Access** you can use the **Add Access** tab to choose options to refine your search to a specific subset of roles and / or access profiles. [![Copy of SN Select Access1]()]() - Description - Name - Owner - Source (searches for access profiles only, not roles) For each filter option you select, the corresponding operator options are displayed beside it. The Description and Name filters offer the following three options for the operator. Expand each one to learn more. 1. **Contains ANY keywords** - Ability to search for ANY keywords - the default option - case insensitive - does not support searching for special characters Example table: | Search Term | Expected Results | Excluded from Results | | --- | --- | --- | | Ep | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic Ad | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Epic Admin | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Epic Admin R | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Ad | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin R | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin Role | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin Role O | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | 2. **Contains ALL the keywords** - Ability to search for ALL keywords - case insensitive - does not support searching for special characters Example table: | Search Term | Expected Results | Excluded from Results | | --- | --- | --- | | Ep | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic Ad | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic Admin | Epic Admin, Epic Admin123, Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Epic Admin R | Epic Admin Role | Admin, Admin123, Admin Role, Admin Role Owner | | Ad | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | | Admin R | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | Epic Admin, Epic Admin123 | | Admin Role | Admin Role, Admin Role Owner, Epic Admin Role | Epic Admin, Epic Admin123, Epic Admin Role | | Admin Role O | Admin Role Owner | Admin, Admin123, Admin Role, Epic Admin, Epic Admin123, Epic Admin Role | 3. **Is exact match (case sensitive)** - Ability to search for EXACT match - case sensitive - supports searching for special characters Example table: | Search Term | Expected Results | Excluded from Results | | --- | --- | --- | | Ep | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Epic | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Epic Ad | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Epic Admin | Epic Admin | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin123, Epic Admin Role | | Epic Admin R | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Ad | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Admin | Admin | Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Admin R | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Admin Role | Admin Role | Admin, Admin123, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | | Admin Role O | | Admin, Admin123, Admin Role, Admin Role Owner, Epic Admin, Epic Admin123, Epic Admin Role | The Owner and Type filters offer one option for the operator; Equals. This operator is read-only and cannot be changed. 1. For **Description** and **Name**, select one of the three provided operators, enter the keyword to search for, and then select the magnifying glass to add the filter. [![Copy of SN Select Access2]()]() 1. For **Owner** and **Source**, select a specific value from the corresponding dropdown list and select the magnifying glass icon to add the filter. [![Copy of SN Select Access3]()]() 1. Combine these filters as needed to refine the results returned. !!! note ```text Unlike access profiles, roles are not associated with a specific source. If you use the Type filter and choose Role, you cannot combine that filter with the Source filter. If you attempt to combine these filters, a message is displayed to notify you that your Source filter will be effectively ignored. ``` 1. When you've finished building your search query, all the search results that match your criteria are displayed. View information about the specific entitlements: 1. To view information about the specific entitlements that comprise an access profile, select the **Details** link in its card. [![Copy of SN Select Access4]()]() 1. To select an access profile or role in the search results, click the top section of the card that contains a check mark and its name, and then select **Next**. [![Copy of SN Select Access5]()]() ### Recommendations Review 1. In stage **3 - Recommendations Review** you can review recommended items in tabular form. 2. Tabbed and pagination helps the user to navigate between result sets. Tabs and their order will be the same as in the Add Access page configuration. 3. The recommendations view is only visible when a single user is selected. It is not applicable for multi-user selections. 4. It's possible for users to ignore recommended items. Refer to the [Access Recommendations]() feature documentation of SailPoint for details. [![e]()]() [![ignore]()]() ServiceNow administrators have the ability to determine whether to display or conceal the recommendation tab by following the steps outlined below. 1. Go to **SailPoint Identity Security Cloud for Service Catalog \> Setup**. 2. For **Show Recommendations, applicable only if required license available?** leave the default value of `Yes` to show the recommendation tab. Change the value to `No` to hide the tab. ### Review & Submit 1. In stage **4 - Review & Submit** you can review the access you are requesting and add comments to help any reviewers make more informed decisions about the request. [![Copy of SN Review Submit1]()]() [![Copy of SN Review Submit2]()]() 1. When you’ve finished reviewing the access being requested and are confident that reviewers will have all of the information they’ll need to make an informed decision on whether or not to grant the access, select **Submit**. #### Account Selection When a user has more than one account on a source, the multi-account feature prompts the requester to choose which account to provision access to, and likewise, each record of a user’s access includes account data to support access revocation from the appropriate account. > [!NOTE] > > Support for the Multi-Account feature has been introduced using widget architecture only and is not supported in the Manage\_Access page. 1. Admins must define one source per system and configure their logic to correlate all of a user’s accounts from that source to their identity. At the end of the request submission flow, when applicable, the access requester is then prompted to select the appropriate account from the list of the target user’s correlated accounts. 2. Request line items, if associated with multiple accounts/assignments, will require a mandatory selection. A window will populate for the requester to make selections. !!! note ```text When the Multi Account feature is disabled This icon does not appear. To understand the functional differences Refer to [Configuring Multi Account](application_level_configuration.md#configuring-multi-account). ``` `isc_request` page - Review & Submit: [![Copy of Acct Selection]()]() `isc_request_2` page - Review & Submit: [![Copy of Acct Selection1]()]() 1. While requesting access, the account name must be selected. [![Acct Selection2]()]() 1. While reviewing access, the assignment must be selected. [![Copy of Acct Selection3]()]() > [!NOTE] > > The SailPoint architecture allows you to request Multi Account access for role, entitlement, and access profile. For revocations, it only supports for role and entitlement. #### Behavioral Differences: OAuth 2.0 vs. Personal Access Token (PAT) Connections The behavior of access removal (revocation) differs based on the type of connection established between ServiceNow and SailPoint. ##### OAuth 2.0 Connection With OAuth 2.0, the ability to request access revocation is governed by the following rules: - Manager-Initiated Revocation: Managers can only request access revocation for their direct reports. - `ORG_ADMIN`: Users possessing the `ORG_ADMIN` role in SailPoint can request access revocation for any user within the organization, irrespective of the reporting structure. - Self-Revocation Restriction: Users are not permitted to request revocation of their own access. - ServiceNow User with `x_sap_intidn.onbehalfof` Role: ServiceNow users with the `x_sap_intidn.onbehalfof` role can initiate access requests on behalf of other users. However, if the ServiceNow user lacks `ORG_ADMIN` privileges in SailPoint, they cannot initiate access revocation requests ##### Personal Access Token (PAT) Access When a PAT is used for the catalog integration, it is automatically granted `ORG_ADMIN` privileges within SailPoint. This results in the following behavior: - Initiate access revocation requests without any restrictions. - The user can select any user visible to them and successfully initiate an access revocation request for that user. ### Determining Other Users' Access as a Manager or Reviewer 1. Sign in to the ServiceNow Portal with your credentials. [![Copy of SN Login]()]() 1. Select **Manage Access**. 2. To review the access for a user who also exists in SailPoint, search for the user and click the top section of the card that contains a check mark and their name, and then select **Next**. [![Copy of SN User Details2]()]() !!! note ```text You can select multiple users and create a request to add the same access to them all at once. You cannot remove access this way, as each user has a unique combination of access. ``` At the top of the page, you’ll see options to **Add Access**, **Recommendations**, and **Review Existing Access**. Use these to request the level of access that’s appropriate for the user. 1. Use the **Add Access** tab to search for roles, access profiles, and entitlements that are currently eligible to be added to the user’s access by selecting the appropriate tab component. For each filter option you select, the corresponding operation is displayed beside it. To filter the search results by owner or source, select a filter from the **Select Filters** list, and then enter the owner or source in the **Keyword Search**. The **Add Access** pagination supports up to 10,000 search results. [![SN See Access]()]() 1. Use the **Recommendations** tab to view recommended access profiles or roles. !!! note ```text - The **Recommendations** tab only displays if you enable the IdentityAI feature in SailPoint for the selected organization - The generation of available recommendations per user requires additional configuration of the SailPoint tenant. For more information about configuration, contact the support team. ``` [![Using the ServiceNow Portal 21]()]() 1. Use the **Review Existing Access** tab to see the access associated with the user's profile. You can select and remove any existing roles or access profiles that are revocable. !!! note ```text A tab to view Entitlements may (or may not) exist. This is based on the setup in Admin settings. ``` [![Copy of SN ReviewDetails]()]() Whether you are adding or removing access, you can view information about the specific entitlements that comprise an access profile by selecting the **Details** link in the access profile’s card. [![Copy of SN Select Access4]()]() 1. When you are finished selecting access to be added or removed, select **Next**. 2. In stage **3 - Review & Submit** you can review the access you are adding or removing and add comments to help any reviewers make more informed decisions about the request. [![Copy of SN Review Submit1]()]() [![Copy of SN Review Submit2]()]() 1. When you're finished reviewing your request to add and / or remove access to determine the appropriate access for one or more users, select **Submit**. 2. A single request containing all related items is generated and assigned a unique number for tracking purposes. 3. Depending on how Access Requests are configured for your site, the request will either be fulfilled automatically, or it will generate a request for manual approval. 4. Administrators can view the current status of requests that have been generated by going to **Account Requests** in the main ServiceNow Service Catalog menu. [![Using the ServiceNow Portal 18]()]() > [!NOTE] > > Suitably entitled users can also view their own requests in the ServiceNow Portal. To view details for a specific request in the list, select its name. [![Using the ServiceNow Portal 19]()]() ## Certification Review After your System Administrator has successfully integrated SailPoint with the ServiceNow Certification Portal, certifiers will be able to view and take appropriate actions related to Certification. For more information about the Certification process, refer to [Certifications Overview](). ### Accessing Certifications 1. Sign in to the ServiceNow Portal with certifier credentials. 2. Select **ISC Certification** to access the application. The certifier will receive a dialog to sign into SailPoint or the equivalent based on the instance integration setup. [![Cert Access]()]() ### Reviewing Certifications 1. Go to **ISC Certification \> Active** tab, and select the certification you want to work on. [![Cert Review]()]() !!! note ```text The value for **Overdue By** may vary due to timezone differences between SailPoint and ServiceNow. ``` 1. Select **Identities** and choose an identity from the list. Review their list of access items within the **Roles**, **Access Profiles**, and **Entitlements** tabs. Select an access item to view its details. [![Cert Review1]()]() 1. In each section, beside each item, select ![]() to approve access or ![]() to revoke access. An item that requires a comment will populate a window for you to explain your decision. For example, if you choose to revoke an item in a role composition certification, you must enter a comment that explains why and how the role should be changed. The system will send a task with these comments to the role owner to update the associated role. !!! note ```text - Roles that were automatically assigned to identities through membership criteria may only be acknowledged. In these cases, select Acknowledge to review this access. - If you revoke an access profile that contains an entitlement that is also assigned to a user through another access profile, all entitlements within the access profile will be revoked, except for the common entitlement. ``` 1. Select **Submit** to submit your comment and complete your review for this access. #### Viewing Recommendations If your organization has the recommendations service enabled on your end, you can use this data to help guide your decision-making process. [![Copy of Cert Review2]()]() 1. Select ![]() for recommended or ![]() for not recommended in the **Decision** column to view the reasons for the recommendation. #### Access Flags When you review an access item for a certification, an icon may display in the **Flags** column. This icon alerts you of information you should consider when approving access. For more information about the icons and their meaning, reference [Access Flags]() in the SailPoint documentation. ### Completing Certifications 1. After you've reviewed each item, you'll be taken to a page to complete your review. !!! note ```text Ensure your decisions are correct and final. Once you've submitted them they cannot be changed, and any access marked as revoked will be removed. ``` 1. Select **Finish**. The certification will then move to the **Completed** tab. [![Complete Cert]()]() ### Viewing Completed Certifications 1. Go to **ISC Certification \> Completed** tab, and select the certification you want to see results for. [![View Completed Cert]()]() 1. Select **Identities** and choose an identity from the list. You'll see a list of access items for that user and the decision you made for each one. [![View Completed Cert1]()]() ### Viewing Campaign Details 1. Go to **ISC Certification**, and select the **Active** tab or **Completed** tab. 2. Select the certification you want to see results for, then select **Show Campaign Details**. Active: [![View Campaign]()]() Completed: [![View Campaign1]()]() 1. Select **Ok** to close the campaign details window. # Widget Customization Widgets are reusable components built using a combination of HTML, CSS, client-side JavaScript, and server-side JavaScript. Base system widgets are read-only components that you can duplicate, modify, and customize as required for user experience and functionality. > [!NOTE] > > Duplicated widgets are classified as custom widgets and will not receive future updates. Updates will be received to the original widgets they were duplicated from. To clone or create widgets, refer to [Developing custom widgets]() in the ServiceNow documentation. To view and configure the instance options for a widget, refer to [Configure widget instances]() in the ServiceNow documentation. ## SPISCUIController Script Widgets developed by SailPoint interact with the server-side using only one script include called SPISCUIController. The script include will accept input in a fixed format, perform actions as per the business logic, and return output in a fixed format. Ensuring that there is a known input and output will enable widgets to interact with this script include, allowing them to forget the server-side complexity and manage only the UI display and interactions. The user experience is dependent on the respective HTML page and portal theme, therefore, you must address any discrepancy that is found. Widgets are rendered using these colors from the portal theme: - brand-primary - brand-danger - brand-warning - brand-success - brand-info ### Scripted Extension Points SPISCUIController checks all implementation for a particular method and calls it from the specific script include. It uses a concept called Scripted Extension Point which allows for a high level of customization. For more information, reference [Using scripted extension points in server-side scripts]() in the ServiceNow documentation. The scripted extension points in the server-side script includes that store JavaScript functions and object classes. By using extension points, you can integrate customizations without altering the core components in the application code. You must create the scripted extension points and add them to the script includes in the base application code. When customizing a base application, you will implement the scripted extension points by creating the custom script includes and registering them against the scripted extension points. When developing an application, create scripted extension points and add them to the script includes in the application code. Use a scripted extension point to designate the specific location where data or objects can be sent to a registered custom script include and where returned results are processed. Perform the following steps to create a new implementation on the SailPoint widgets. 1. Go to **System Extension Points \> Scripted Extension Point**, and search for the `x_sap_intidn.ISCUIHandler` extension point. 2. Select the **Create Implementation** link from the form, and provide and appropriate name to the implementation. 3. The `handles()` method determines if this implementation handles the request from SPISCUIController. 4. Each implementation has a column `order`. SPISCUIController first checks implementations with a lower value of the order field. If you have only one implementation that overwrites all the methods, you can create an implementation with an `order` value lower than 9999. 5. Ensure all the methods are appropriately defined. Each method will receive a fixed set of parameters from widgets, and widgets will expect a same set of return. Always refer to the SPISCDefaultUIHandler implementation to know the expected parameters and expected return of each method. # SailPoint Widget Library > [!NOTE] > > Widgetized architecture has been introduced in v4.0 to provide flexibility to configure and customize the behavior of the app. Widgets will be released and you will have the choice to select and customize them as per your business needs. SailPoint has developed widgets that can be directly utilized in your Service Portal, record producer, or customized request pages to align with your specific business requirements. The widgets are as follows: > [!NOTE] > > - Base system widgets are designed as read-only components to allow you to take advantage of upcoming updates. If you wish to make modifications, you have the option to duplicate these base system widgets. It's important to note that duplicated widgets are classified as custom widgets and will not receive any future updates from the original widgets they were duplicated from. > - To clone or create widgets, refer to [Developing custom widgets]() in the ServiceNow documentation. > - To view and configure the instance options for a widget, refer to [Configure widget instances]() in the ServiceNow documentation. Use the following pages to find information about the available widgets and customization options: - [Widgets for Request and Review Access]() lists widgets used to request and review access, including their release versions and instance options. - [Widgets for Certification]() lists widgets used for certification reviews. - [Widget Customization]() describes the components, scripts, and extension points used to customize widgets. # Widgets for Certification | Widget | Instance options | Release version | Updated version | | --- | --- | --- | --- | | ISC Login for Certification | None | v5.0 | | | ISC Campaign Certifications List | None | v5.0 | | | ISC Certification Access Review Items | Two | v5.0 | v5.1 | | ISC Certification Identity List | One | v5.0 | | | ISC Certification Campaign Details | None | v5.0 | | | ISC Certification Recommendation | None | v5.0 | | ## ISC Login for Certification This widget enables the necessary authentication to establish connections with SailPoint instances. [![Cert Access]()]() ## ISC Campaign Certifications List This widget displays all the certifications assigned to users. [![Cert Review]()]() ## ISC Certification Access Review Items This widget displays all access items that need to be reviewed or have already been reviewed for the user. [![Cert Review3 1]()]() [![Cert Review3 2]()]() - Items Per Page (Default 5) - Select the number of access objects to be shown in the widget. - Details Pop-Up Window (Default: False) - Enabling this option displays the **Details** column. - This popup can be customized to display additional information as required. Some basic information has been pulled on to this page for sample. ## ISC Certification Identity List This widget displays a list of identities with pending or completed decisions. Select **Show Campaign Details** to view additional information about the respective campaign. Use the search option to filter identities within the list. Select **Exit Certification** to exit the current process and return to the landing page. [![Cert Review4]()]() - Items Per Page (Default 10) - Select the number of identities to be shown in the widget. ## ISC Certification Campaign Details This widget displays the details of the selected certification. [![Cert Campaign Details]()]() ## ISC Certification Recommendation This widget lists all the the reasons behind the recommendation. [![Cert Recommended]()]() # Widgets for Request and Review Access This table provides information about the Release version and Updated version of each widget. You can also check the instance options of all widget. | Widget | Instance options | Release version | Updated version | | --- | --- | --- | --- | | ISC Access Object Details | None | v4.0 | v5.2 | | ISC Access Object Selection | Multiple | v4.0 | v5.2 | | ISC Access Object Selection 2 | Multiple | v4.0 | v5.2 | | ISC Selected Users | None | v4.0 | v4.0 | | ISC Review And Submit | Multiple | v4.0 | v5.3 | | ISC Review And Submit 2 | Multiple | v4.0 | v5.3 | | ISC Header Text | None | v4.0 | \- | | ISC Progress Bar | None | v4.0 | \- | | ISC Access Comment | None | v4.0 | \- | | ISC User Search | None | v4.0 | \- | | ISC Footer Buttons | None | v4.0 | \- | | ISC Login | None | v4.0 | \- | | ISC Access Type | None | v4.0 | v5.2 | | ISC Sunset Date | Multiple | v4.0 | v4.1 | | ISC Access Object Search | Multiple | v4.0 | v5.4 | | ISC User Selection | Multiple | v4.0 | v4.1 | | ISC User Selection 2 | Multiple | v4.0 | v4.1 | | ISC Questionnaire | None | v4.0 | v4.1 | | ISC Access Object Free Text Search | Multiple | v5.2 | \- | ## ISC Access Object Details This widget displays the details of the linked access profiles and entitlements when **Details** is selected. [![ISC Access Object Details]()]() ## ISC Access Object Selection [![ISC Access Object Selection]()]() | Field | Description | | --- | --- | | Show Non-Requestable access objects under Add Access | A checkbox to show non-requestable objects under the Add Access tab. | | Show Non-Revocable access objects under Remove Access | A checkbox to show non-revocable objects under Remove Access tab | | Show Disabled access objects under Add Access | A checkbox to show disabled objects under the Add Access tab (only applicable for Roles and Access Profiles) | | Show Disabled access objects under Remove Access | A checkbox to show disabled objects under Remove Access tab (only applicable for Roles and Access Profiles) | | List and order of Search results tab | Specify the list and order of object types in comma separated values. | | Items Per Page | Select the number of access objects to be shown in the widget. | | Encoded Query for items under Add Access | An optional and advanced parameter to refine your search results in the 'Add Access' tab. You can apply an extra filter query that works on roles, access profiles, and entitlements. | | Encoded Query for items under Remove Access | An optional and advanced parameter to refine your search results in the 'Remove Access' tab. You can apply an extra filter query that works on roles, access profiles, and entitlements. | [![ISC Access Object Selection new]()]() ### Encoded Query Additional Instructions Encoded Query will be applied on page load. SailPoint recommends using this option judiciously as it might result in empty record set which would be confusing to end users as no warning is displayed. Additionally, you must validate the scenario if the Native Search functionality is used. SailPoint recommends using different pages for the native search redirection and restricted user search functionality. For more information refer to [Searchable Fields - SailPoint Identity Services](). ### List and Order of Search Results Tab (for Native Search Only) - If you set the **List and order of Search results tab. Exact text separated by comma to be used. Refer to documentation for examples** (x\_sap\_intidn.x\_sp\_spnt\_snow\_int.specify\_tab\_order) property to “Roles” only and the Native Search Redirect Page ID (example: manage\_access) property to “isc\_request”, and you configure the widget option for access tabs on this page to “Access Profiles”, the following occurs. When a user searches for a role on the portal, the user finds only “Roles” in the search result because the native search uses this property. - When the user selects a role to submit a request, the system takes the user to the page with the role selected, and the user can submit the request even if the widget option is configured for “Access Profiles” only. - However, if the user clicks the "Previous" button, the system loses the selected role (from the native search). As the widget option is set to “Access Profile”, the user will then only see access profiles. ### Do's and Dont's for List and Order of Search Results Tab It’s important to note that the property will only work if you apply the following standards: #### Do's - Use the names of the tabs as they are specified, capitalizing the first letter. The default values are “Roles”, “Access Profiles”, “Entitlements”. - Enter the values, separated by a comma, in the order that you want the tabs to display. The functionality will work whether you choose to include (or not include) spaces before or after the commas. For example, - “Access Profiles, Roles, Entitlements” - “Entitlements, Roles, Access Profiles“ - “Roles, Entitlements” - “Access Profiles” #### Dont's - Do not change the names of the tabs in any way. For example, - “roles, access profiles, entitlements” - To work correctly, the first letter of each name must be upper-case. - “Access Profiles” - To work correctly, all letters other than the first letter must be lower-case. - “ENTITLEMENTS” - To work correctly, the first letter should be upper-case followed by all lower-case letters. - Do not include special characters, extra punctuation, extra letters, or acronyms in the names of the tabs. - “Roles.Access Profiles.Entitlements” - “Access Profiles-Entitlements.” - “A.Profiles” - “Access\_Profiles” #### How to Reorder the Search Results Tabs Reorder the tabs of the application by reordering them in the property. By default, the order is “Roles, Access Profiles” which displays the **Roles** tab first, followed by the **Access Profiles** tab. [![Roles1]()]() If you want to show the “Access Profiles” tab first, then you must change the value of the property to “Access Profiles, Roles”, which will display the **Access Profiles** tab first, followed by the **Roles** tab. [![Copy of Roles2]()]() ## ISC Access Object Selection 2 This widget allows you to select searched results of Roles, Access Profiles, and Entitlements in tabular mode. [![Copy of Access Obj Selection 2]()]() | Field | Description | | --- | --- | | Show Non-Requestable access objects under Add Access | A checkbox to show non-requestable objects under the Add Access tab. | | Show Non-Revocable access objects under Remove Access | A checkbox to show non-revocable objects under Remove Access tab | | Show Disabled access objects under Add Access | A checkbox to show disabled objects under the Add Access tab.(only applicable for Roles and Access Profiles) | | Show Disabled access objects under Remove Access | A checkbox to show disabled objects under Remove Access tab.(only applicable for Roles and Access Profiles) | | List and order of Search results tab | Specify the list and order of Access objects in comma separated values. | | Secondary Columns to be displayed (example: description, type, owner) | Ability to select secondary columns to be shown on the table. The Name and Details columns are mandatory and fixed. | | Items Per Page | Select the number of access objects to be shown in the widget. | | Encoded Query for items under Add Access | An optional and advanced parameter to refine your search results in the 'Add Access' tab. You can apply an extra filter query that works on roles, access profiles, and entitlements. | | Encoded Query for items under Remove Access | An optional and advanced parameter to refine your search results in the 'Remove Access' tab. You can apply an extra filter query that works on roles, access profiles, and entitlements. | > [!NOTE] > > Column names are case sensitive. [![Copy of ISC Access Object Selection 2 New]()]() ### Encoded Query Additional Instructions Encoded Query will be applied on page load. SailPoint recommends using this option judiciously as it might result in empty record set which would be confusing to end users as no warning is displayed. Additionally, you must validate the scenario if the Native Search functionality is used. SailPoint recommends using different pages for the native search redirection and restricted user search functionality. For more information refer to [Searchable Fields - SailPoint Identity Services](). ### List and Order of Search Results Tab (for Native Search Only) - If you set the **List and order of Search results tab. Exact text separated by comma to be used. Refer to documentation for examples** (x\_sap\_intidn.x\_sp\_spnt\_snow\_int.specify\_tab\_order) property to “Roles” only and the Native Search Redirect Page ID (example: manage\_access) property to “isc\_request”, and you configure the widget option for access tabs on this page to “Access Profiles”, the following occurs. When a user searches for a role on the portal, the user finds only “Roles” in the search result because the native search uses this property. - When the user selects a role to submit a request, the system takes the user to the page with the role selected, and the user can submit the request even if the widget option is configured for “Access Profiles” only. - However, if the user clicks the "Previous" button, the system loses the selected role (from the native search). As the widget option is set to “Access Profile”, the user will then only see access profiles. ### Do's and Dont's for List and Order of Search Results Tab It’s important to note that the property will only work if you apply the following standards: #### Do's - Use the names of the tabs as they are specified, capitalizing the first letter. The default values are “Roles”, “Access Profiles”, “Entitlements”. - Enter the values, separated by a comma, in the order that you want the tabs to display. The functionality will work whether you choose to include (or not include) spaces before or after the commas. For example, - “Access Profiles, Roles, Entitlements” - “Entitlements, Roles, Access Profiles“ - “Roles, Entitlements” - “Access Profiles” #### Dont's - Do not change the names of the tabs in any way. For example, - “roles, access profiles, entitlements” - To work correctly, the first letter of each name must be upper-case. - “Access Profiles” - To work correctly, all letters other than the first letter must be lower-case. - “ENTITLEMENTS” - To work correctly, the first letter should be upper-case followed by all lower-case letters. - Do not include special characters, extra punctuation, extra letters, or acronyms in the names of the tabs. - “Roles.Access Profiles.Entitlements” - “Access Profiles-Entitlements.” - “A.Profiles” - “Access\_Profiles” #### How to Reorder the Search Results Tabs Reorder the tabs of the application by reordering them in the property. By default, the order is “Roles, Access Profiles” which displays the **Roles** tab first, followed by the **Access Profiles** tab. [![Roles1]()]() If you want to show the “Access Profiles” tab first, then you must change the value of the property to “Access Profiles, Roles”, which will display the **Access Profiles** tab first, followed by the **Roles** tab. [![Copy of Roles2]()]() ## ISC Selected Users This widget displays the initials of the selected users. Hover the mouse cursor over the initials to view additional details. To remove the user, select the red x on the initials. [![ISC Selected Users]()]() ## ISC Review And Submit This widget displays the line items of selected users and selected objects for adding or removing access. Select Validate/Submit to see related warnings and errors. [![Copy of ISC Review Sub]()]() - Display Expiration Date - When selected, the field is displayed. Deselect this option to hide the expiration date field. - Expiration Date Default Value - If the field is displayed, select the default value of the expiration date. If the field is hidden, the value will be ignored. - Expiration Date Mandatory - When selected, this forces the end users to have a value in the expiration date field. - Show Additional Information - When selected, this allows end users to provide additional information required for the chosen access object. - Additional Information Response Requirement - Mandatory Questions Only: When this option is selected, the additional information box is highlighted in red if it is visible and contains at least one mandatory question. - Response Required Per Access: When this option is selected, the additional information box is highlighted in red for every access item where the box is visible, regardless of whether any mandatory questions exist. [![Instance option]()]() ## ISC Review And Submit 2 This widget displays the following additional details: - **Comment** - **Expiration Date** - **Account Selection** (for adding access) / **Assignment Selection** (for revoking access) - **Additional Information** > [!NOTE] > > The **Comment**, **Account Selection**, and **Assignment Selection** fields are populated based on the settings in SailPoint. The **Expiration Date** and **Additional Information** are based on the configuration in ServiceNow. [![Copy of ISC Review Sub2]()]() - Display Expiration Date - When selected, the field is displayed. Deselect this option to hide the expiration date field. - Expiration Date Default Value - If the field is displayed, select the default value of the expiration date. If the field is hidden, the value will be ignored. - Expiration Date Mandatory - When selected, this forces the end users to have a value in the expiration date field. - Show Additional Questions - When selected, this allows end users to provide additional information required for the chosen access object. - Additional Information Response Requirement - Mandatory Questions Only: When this option is selected, the additional information box is highlighted in red if it is visible and contains at least one mandatory question. - Response Required Per Access: When this option is selected, the additional information box is highlighted in red for every access item where the box is visible, regardless of whether any mandatory questions exist. [![Instance option]()]() > [!NOTE] > > This widget has been designed based on the most commonly used fields. If the interface is not aligned for your use, you can customize and change the HTML of the widgets. ## ISC Header Text This widget displays the static text on every page, which is generally used to give instructions to end users. The HTML value of the text is extracted from the setup page. [![ISC Header Text]()]() ## ISC Progress Bar This widget tracks the progress of the requester. [![ISC Progress Bar]()]() ## ISC Access Comment This widget is used to accept the comments. [![ISC Access Comment]()]() ## ISC User Search This widget is used to search for users. [![ISC User Search]()]() ## ISC Footer Buttons This widget is used to move across the pages via the **Previous**, **Next**, and **Cancel** buttons. The position of the buttons can be aligned in the container, and is dependent on widget options. [![ISC Footer Buttons]()]() ### Instance Options for This Widget (ServiceNow Admin User) Align the buttons to the edge or center. ## ISC Login This widget enables the necessary authentication to establish connections with SailPoint instances. It does not have a display component. ## ISC Access Type The visibility of this widget is dependent on the configuration of the setup page as well as users selected. [![ISC Access Type]()]() - Show "Remove Access" tab. - Select a checkbox to show/hide “Remove Access” tab. - Show "Recommendations" tab, applicable only if required licence available. - Select a checkbox to show show/hide “Recommendations” tab. !!! note ```text If you unselect both options, this widget will be hidden. To set instance option again, use the Service Portal Page Designer. ``` ## ISC Sunset Date This widget functions as a date picker specifically designed for selecting the Sunset date. [![ISC Sunset Date]()]() - Display Expiration Date - When selected, the field is displayed. Deselect this option to hide the expiration date field. - Expiration Date Default Value - If the field is displayed, select the default value of the expiration date . If the field is hidden, the value will be ignored. - Expiration Date Mandatory - When selected, this forces the end users to have a value in the expiration date field. [![Sunset Widget]()]() ## ISC Access Object Search This widget filters the requestable entitlements, access profiles and roles dependent on the criteria provided by the requester. [![ISC Access Object Search]()]() - Default Filter - Choose a filter that will be chosen by default when the page loads. You can select **Name**, **Description**, **Owner**, **Source**, **Application** or **Additional Search**. Keep **\-- None --** if you would like no pre-selection. - Default Operator - If the default filter is **Name** , **Description** or **Additional Search** the default operator is applicable and allows you to select **Contains ANY keywords**, **Contains ALL the keywords**, or **Is EXACT match**. If the default filter **\--None--** is selected , **Contains ANY keywords** will be auto-selected for the default operator. If the default filter is **Owner**, **Source** or **Application** the default operator will always be **Equals** and this option will be ignored. - Quoted phrase search - When the operator is Contains ALL the keywords, enclose a multi-word term in double quotes to match the exact phrase. - This applies to the Name, Description, and Additional Search filters. - Sales Force Admin - The each word is a separate keyword. All words must match, in any order. - "Sales Force Admin"- The exact phrase must match. Partial or reordered matches are excluded. - "Sales Force Admin" Jira - The phrase and the keyword must both match. > **Note** > > Quoted phrase search applies only when the operator is Contains ALL the keywords. - Search by Filter Option List - Lists the filter options to be enabled for search. The options in the dropdown will be displayed as in the order mentioned in the widget. Supported values are: - Name - Description - Owner - Source - Application - Additional Search Any values outside of this list will be ignored. If no values are specified, the default filter options will be displayed. The **Default Filter** and **Default Operator** should be set based on the values defined in the **Search by Filter Option List**. - Additional Search With this option, users can now search for any searchable field of an access object in SailPoint. The search is no longer limited to only predefined fields such as name, description, owner, and application. It can even be used to search from meta data and tags. - Additional Search Label : Users can customize the Additional Search dropdown label by configuring the widget property Additional Search Label. - Additional Searchable Fields : Users can define searchable fields in widget options using Additional Searchable Fields. Provide values as a comma-separated list. Example: `accessModelMetadata.name,accessModelMetadata.valueName,tag` `CustomName` [![Copy of Additional Search]()]() > [!NOTE] > > No validations are performed in widget options, thus admins need to be cautious while configuring. ## ISC User Selection This widget lists all of the users by default, and gives the option to filter the users based on your selections. [![ISC User Selection]()]() - Number of user records to be displayed per page - Optional field names to display - Specify the ServiceNow user table field names separated with a comma, e.g., email,manager,department - Encoded Query - This is an optional parameter that must be used with caution. It is used to further filter the users on top of the result set retrieved from SailPoint. By default, the manager will be able to see their own users along with team members. Admin and OnBehalfOf roles will retrieve all users. The widget option provides the ability to provide additional query parameters. This encoded query will be applied on page load. We recommend using this option carefully as it might result in an empty record set, which could confuse end users since there is no warning message displayed. If there are field level ACLs applied on any of the fields used in the encoded query, end users may see error messages logged on their screen. SailPoint recommends extensive testing with all personas before using this widget option. If you're using the Native Search functionality, it is recommended to validate the scenario, as well as use different pages for native search redirection and restricted user search functionality. ## ISC User Selection 2 This widget allows you to select a maximum of 10 users via the dropdown. [![User Selection 2]()]() - Optional field names to display - Specify the ServiceNow user table field names separated with a comma, e.g., email,manager,department - Encoded Query - This is an optional parameter that must be used with caution. It is used to further filter the users on top of result set retrieved from SailPoint. By default, the manager will be able to see their own users along with team members. Admin and OnBehalfOf roles will retrieve all users. The widget option provides the ability to provide additional query parameters. This encoded query will be applied on page load. We recommend using this option carefully as it might result in an empty record set, which could confuse end users since there is no warning message displayed. If there are field level ACLs applied on any of the fields used in the encoded query, end users may see error messages logged on their screen. SailPoint recommends extensive testing with all personas before using this widget option. If you're using the Native Search functionality, it is recommended to validate the scenario, as well as use different pages for native search redirection and restricted user search functionality. ## ISC Questionnaire This widget displays questions configured for the selected access object. It's editable to allow for customization without the need to modify other widgets. [![ISC Questionnaire]()]() ## ISC Access Object Free Text Search This widget allows users to filter requestable entitlements, access profiles, and dependent roles based on the text search term they enter. [![Access object free text search]()]() > [!NOTE] > > Below Instance Options are only applicable for Add Access tab. - Searchable Fields - Specify the list of fields to be searched, separated by commas. Example: name, description, owner.name - Match any term - A checkbox indicating whether at least one of the entered search terms should match within the specified fields. [![Acess object search new]()]() > [!NOTE] > > You can apply an extra filter query that works on roles, access profiles, and entitlements. For more information refer to [Searchable Fields - SailPoint Identity Services]()