Troubleshooting ServiceNow Access and Synchronization Issues

Use Case

When integrating with ServiceNow, you may choose to restrict your dedicated user’s access to specific tables to enforce boundaries. However, overly strict limitations can lead to insufficient permissions, preventing Getint from retrieving data correctly and disrupting synchronization.

Out-of-the-box (OOB) modules installed via the Application Manager may require specific ACLs to be assigned to the dedicated user's role to access necessary tables and ensure proper syncing.

This guide walks you through how to grant the required permissions or troubleshoot common access issues that may appear during setup.

Assign OOB Roles for Easier Setup

Base OOB roles can be assigned to your dedicated user to grant read, write, and create access to the Incident, Problem, and Change tables.

If you’re encountering access errors when syncing these work items and prefer not to assign the more extensive ITIL role, consider using OOB roles customized to your needs.

Understanding Roles in ServiceNow

Roles in ServiceNow can inherit other roles, which helps with permission management. You can view these associations by navigating to:

System Security > Users and Groups > Roles

Locate a specific role and click to see inherited roles in the Contains Roles tab.

Additionally, roles can include specific ACLs to grant change permissions and access to various tables.

Role Access Breakdown

Incident

• sn_incident_read Grants read access to Incident records.

• sn_incident_write Enables creation and editing of Incident records.

sn_incident_read role

sn_incident_write role

Change

• sn_change_read Provides read access to Change records.

• sn_change_write Allows creation and modification of Change records.

sn_change_read role

sn_change_write role

Problem

• sn_problem_read Enables reading of Problem records.

• sn_problem_write Supports creating and editing of Problem records.

Each role displays inherited permissions in the Contains Roles tab at the bottom.

sn_problem_read role

sn_problem_write role

Removing Unwanted ACLs from OOB Roles

If you're concerned about assigning OOB roles that may include excessive permissions, you can query ACLs and trim them to fit your integration scope.

Steps to Query ACLs

1. In the Application Navigator, type sys_security_acl_role_list.do and press Enter.

1. It will lead you to a page that lists all ACLs within your ServiceNow workspace. You can then filter the ACLs by role.

1. Running the filter with conditions ROLE - IS - [yourRoleName] will output all ACLs associated with the specified role. You can then customize all ACLs assigned to the specified role (you can also add tags to each ACL, so you can track their operation type, as you won’t be able to see it through this screen).

Adding ACLs for Vendor and Scoped Applications

For integrations involving modules like Customer Service Management (CSM) or Project Portfolio Management (PPM), dedicated users must have ACLs aligned with corresponding work item tables.

For example, syncing the Project work item from PPM requires read, write, and create ACLs for the Project table. Without these, syncing will fail even if mappings exist in Getint.

View of the Project Portfolio Management, through the Application Manager.

Example Error:

{"message":"Insufficient rights to query records","detail":"Field(s) present in the query do not have permission to be read"}

Dedicated user doesn’t have read ACL for the Project table.

After installing a vendor application, you must create ACLs corresponding to the table and work item that you’d like to synchronize. Make sure to assign the ACLs to the dedicated user’s role:

In this case, we installed Project Portfolio Management. Searching for Project in the name dropdown of the ACL creation screen fetches the right table for the work item Project that we are looking to sync.

After assigning the Read ACL for the Project table to the dedicated user's role, Getint successfully retrieved items from the Project table. However, because the Create ACL was still missing, the integration was unable to generate new Project work items in ServiceNow.

To ensure smooth data synchronization, confirm that the dedicated user's role includes all required ACLs. These typically include Read, Write, and Create permissions for the relevant tables.

Ensure to add Read, Write, and Create ACLs to the dedicated user’s role for the integration to run smoothly.

Working with Scoped Applications

• Scoped applications like CSM operate in isolated environments. You cannot use the .* ACL operator unless you change the global scope. This ACL operator is required for Getint to synchronize data, and without the ACLs with this operator you might experience access issues.

.* ACL is missing from the dropdown, as we are not in the scope of the application.

• To change your current scope, click the Application Scope icon, and then click on the first option:

• Filter the application by name, then click it. When the application is selected, your ServiceNow tab should refresh, and the global scope will change the one selected:

You can confirm that you are within the scope of the application by hovering your mouse over the application scope icon.

• You should now be able to create ACLs of the scoped application’s tables with the .* operator:

The .* operator for ACL can now be selected, as we are within the application’s scope.

Debugging Field-Level ACLs

You can debug individual work item fields to uncover their ACLs, identify missing permissions, and assign only those needed for syncing. This lets you control which fields Getint can access while excluding any restricted data.

How to Debug Fields

1. Type Debug Security in the navigator, and select Debug Security Rules under System Security.

Avoid impersonating before opening the Debug application. Doing so will prevent access, even if the user has the script_debugger role. Instead, open the Debug application first and impersonate after the debug window is active.

1. The Debug application window will appear. Impersonate the user, minimize the window, and navigate to the work item you want to debug.

Debug application window.

1. When debugging is active, a small Bug icon appears beside fields governed by ACL rules. Clicking it reveals the applicable ACLs and their evaluation results.

1. The fields appear greyed out, indicating the dedicated user lacks Write permissions, even though they have access to the Incidents application and table.

A True result for a Read ACL means the dedicated user has a role with Read access to the field.

A False result for a Write ACL means the user lacks Write permission for the field.

1. Granting Write ACL for the Urgency field to the dedicated user’s role enables editing of that field.

Write ACL for the Incident's Urgency field has been added to the getint_integration role assigned to the dedicated user.

1. The field is no longer greyed out, and its values are now editable.

Getint can now sync the Urgency field, while leaving the data of other unwanted fields out of access.

Fields Not Visible Due to Business Rule

When reducing the access of the dedicated user, or when limiting its ACLs/roles, you may notice some fields missing from the work item:

Fields such as Assignee and Assignment Group are missing from the view.

If the dedicated user doesn't have ITIL or snc_incident_read roles, trying to switch the view from Self-Service to Default to display those missing fields will always switch it back to Self-Service. This happens due to a Business Rule in place. You can add the dedicated user role to the list of roles allowed to switch the view to default with the following process:

• Type Business Rules in the application navigator, and select the option under System Definition.

• Type incident in the search bar, and click on the Incident Functions option:

• Switch to the Advanced tab, and copy this text (from the first space until the penultimate parenthesis):

• Paste the text right after the penultimate parenthesis, and change the "sn_incident_read“ role for the role you have created for your dedicated user (in my case, it’s getint_integration):

• Now the dedicated user should be able to switch views to Default, without it switching back to Self-Service, allowing you to visualize the fields from the work item properly while logged in through the dedicated user (or while impersonating it):

Default View can now be selected, and the fields previously not visible are now displayed.

Summary

Use these steps to control what Getint can access and sync from ServiceNow.

• For a straightforward setup, assign OOB roles.

• To limit permissions, query ACLs, remove excess, and customize the role.

• Vendor applications like PPM or scoped apps like CSM require targeted ACLs. Make sure to switch scopes and add . * ACLs as needed.

• Debug field-level permissions to ensure the user can read and write the intended fields.

If you need any further help or if you are experiencing issues with your installation, feel free to open a support ticket at our Support Portal.

Start your integration journey. Schedule a free consultation with our Getint Integration Expert today!