ServiceNow configuration

Public preview: The federated search and actions features are in public preview. This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of the Service Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see the launch stage descriptions.

This page describes how to set up and configure a third-party configuration before creating the ServiceNow data store.

ServiceNow sites

ServiceNow offers two primary sites:

1. Developer Site:

   • Configures the knowledge base, sets up workflows, and develops custom applications.
   • URL: https://developer.servicenow.com.
   • Sign in using your ServiceNow ID.

2. Main ServiceNow site [ServiceNow site for _Personal Developer Instance (PDI)]: The site for your ServiceNow instance.

   • Manages users, groups, and system administration tasks.
   • URL: The URL for your ServiceNow instance.
   • Sign in using your administrator credentials.

Note: For the following setup, use the Main ServiceNow site for configuration on OAuth and permissions.

Create ServiceNow account

To create a ServiceNow account in Developer Site and create a PDI instance do the following:

1. Go to developer.servicenow.com and click Sign in.

2. Select New user? Get a ServiceNow ID.

3. Enter the necessary information, and click Sign Up. Use your email and verify it using the confirmation link sent to your inbox.

To create a Personal Developer Instance (PDI):

1. Sign in to the Developer site using your account credentials and accept the terms.
2. Click Request instance. After provisioning, a confirmation dialog states: "Your instance is ready!".
3. Save the displayed instance URL, an admin username, and a password.
4. To access your new environment, click the Start Building button on the Developer Site header. This opens your instance in a new tab.

Note: Upon initial login with full administrative privileges, go to User Administration > Users to change the default admin password for security.

Developer instance

Obtain authentication credentials

To create an OAuth endpoint and obtain the authentication credentials, do the following:

1. Sign in to the PDI ServiceNow instance using the administrator credentials you obtained in the Create ServiceNow account section.

2. Navigate to All > System OAuth > Application registry.

3. In the Application registries page, click New.

4. In the OAuth application page, click Create an OAuth API endpoint for external clients.

5. In the New record page, enter the following mandatory fields:

   1. Name: Enter a unique name.
   2. Redirect URL: Enter the redirect URL: https://vertexaisearch.cloud.google.com/console/oauth/servicenow_oauth.html

6. Click Submit to create the credential.

7. After submission, click the name to view the Client ID.

8. The secret is masked. Click the lock icon next to it to unmask and view the client secret.

9. Save the Client ID and Client secret for later use.

Set up administrator role

To elevate your own role to security_admin, do the following:

1. Sign in to ServiceNow account.

2. Click your profile icon and then select Elevate role.

3. Select security_admin and then click Update. The security_admin role helps to create roles and manage users.

To grant the security_admin role to another user:

1. Select All, and then select Users under User Administration.

2. Locate and select the user for whom you need to elevate the role.

3. From the Roles tab, click Edit.

4. Select the security_admin role from Collection and add it to the Roles List.

   Note: The user with the security_admin role must then click their profile icon and select Elevate Role to use it.

Set up user roles and permissions

To create a ServiceNow data store in Gemini Enterprise, you need to grant the appropriate roles and permissions to users.

The following are the options to set user roles and permissions to your ServiceNow instances:

• Create a custom role with ACL rules (Recommended)

• Use a custom role with entity administrators

• Use an administrator role

For more information about visibility and access control, see Incident visibility and access control

Create a custom role with ACL rules (Recommended)

Create a custom role with the minimum set of permissions.

Note: This procedure provides the most secure and restrictive access to the incident entity. Users are only able to find incidents with which they are directly associated. For more information, see Incident visibility and access control.

1. Go to All > User administration > Roles.

2. Click New.

3. Enter a name and Submit.

4. Go to System security > Access control (ACL).

5. Click New to create a new ACL rule.

6. Repeat the following two steps until you grant access to all required tables.

   1. Use sys_user_role as an example to see how table access is granted.

   2. Click Submit and select the role.

Required table access

The connector needs access to these tables for each entity to run.

Table name	Description
incident	Show incidents in search results.
sc_cat_item	Show catalog items in search results.
sc_cat_item_user_criteria_mtom	Show users who can access catalog items based on user criteria.
sc_cat_item_user_criteria_no_mtom	Show users who can't access catalog items based on user criteria.
sc_cat_item_user_mtom	Show which users can access catalog items.
sc_cat_item_user_no_mtom	Show users who can't access catalog items.
kb_knowledge	The list of knowledge articles that can be shown in search results.
kb_knowledge_base	The list of knowledge bases that can be shown in search results.
kb_uc_can_contribute_mtom	Show who can contribute to knowledge bases based on user criteria.
kb_uc_can_read_mtom	Show who can read knowledge bases based on user criteria.
kb_uc_cannot_read_mtom	Show who can't read knowledge bases based on user criteria.
sys_user_role	List of roles that can be assigned to users.
sys_user_has_role	List of roles mapped to the users.
sys_user_group	List of user group segments.
sys_user_grmember	List of group members for groups.
sys_user	List of all users.
core_company	List of all company attributes.
cmn_location	List of all location attributes.
cmn_department	List of all department attributes.
user_criteria	List of user criteria records.
sp_portal	Link portal URI in search results.
m2m_sp_portal_knowledge_base	Link portal URI for knowledge articles in search results.
m2m_sp_portal_catalog	Link portal URI for catalog items in search results.

Grant and verify ACL access

The connector requires ACL access to the catalog item fields of the sc_cat_item table.

To grant and verify access, do the following:

1. Grant explicit access by creating a new ACL rule and manually entering sc_cat_item.* in the Name field of the form.

   

   Enter `sc_cat_item.*`

2. Verify that the ACLs are updated.

3. Go to sys_security_acl_role_list.do in the search bar.

4. Set Role to the role that you want to verify.

   

   Select role to verify

5. Verify that the required ACLs are assigned to the role.

Use a custom role with entity administrators

Using the administrator role may not suit teams or organizations that want to avoid assigning overly powerful permissions. This option provides a role with three specific permissions that grant the required access.

1. Go to All > System security > Users and groups > Roles.

2. Select New, enter a name.

3. Click Submit.

4. Find the created role in the list.

5. Navigate to Contains roles > Edit.

6. Add the following roles to the newly created role, and then click Save.

   • catalog_admin
   • knowledge_admin
   • incident_manager

   

   Add roles and click the Save button

7. Confirm the updated roles.

   

   Confirm roles

Use an administrator role

You can use an administrator role to pull data. Use the default administrator role configured with the instance, or create a new user with an administrator role by doing the following:

1. Go to All > User administration > Users.

2. Create a new user.

3. Enable Web service access only. When you select Web service access only, you create a non-interactive user.

   • Interactive users can log in to the ServiceNow UI and service portal using standard credentials or SSO, with full access to UI pages and API endpoints.
   • Non-interactive users have restricted UI access and are limited to authorizing programmatic API connections for service-to-service integration.

4. After user creation, select the user from the users list.

5. Click Roles > Edit.

6. Add Admin.

7. Click Save to add a list of roles to the user.

8. Click Set password, auto-generate it, and save it.

Grant role to a user

1. Go to All > User administration > Users.

2. Find or create a new user.

3. If no user is available, go to System security > Users and groups > Users.

4. Click New.

5. Create a new service account in the user table. Make sure to click Web service access only.

6. Scroll to Roles.

7. Click Edit.

8. Grant the role you created and assign it to the user. Based on the type of role you created in the previous step, select the appropriate one and assign it to the user. Click Save.

9. View the custom role with ACL.

10. Obtain the username and password for the user and click Set password.

11. Auto-generate a password and keep it for later use.

Incident visibility and access control

To enhance security and prevent unintentional data exposure, the ServiceNow connector uses restrictive access control for the incident entity. This ensures that end users can only view incidents with which they are directly associated.

As part of this restrictive approach, the connector doesn't honor broad, role-based permissions for incident visibility. Standard ServiceNow roles such as itil and sn_incident_read, which might grant a user visibility over all incidents in the ServiceNow UI, don't grant the same level of access in Gemini Enterprise.

Users with any of the following roles have global incident visibility and can view all incidents:

• admin
• incident_manager
• change_manager

All other users can only view an incident if they have opened, reopened, resolved, or closed the incident. They can also view an incident if they are:

• In the assignment group for the incident.
• A caller associated with the incident.
• An assignee.
• In a watch list.
• In a work notes list.
• In an additional assignee list.

This behavior prevents a user of Gemini Enterprise from finding an incident to which they don't have access. Because of the additional restrictions compared to the broader ServiceNow permissions, this behavior may occasionally prevent a user from finding an incident in Gemini Enterprise to which they have access in ServiceNow.