Setting Up ServiceNow Scopes and Roles for Non-Admin Integrations

This guide explains the minimum roles and Access Control Lists (ACLs) a user needs in ServiceNow to allow your integration (such as Merge) to read and write data through the ServiceNow REST API.

Using these scoped permissions ensures least-privilege access while maintaining full compatibility with core ITSM and CSM functionality.

Overview

ServiceNow uses roles and ACLs to control who can read, create, and update data.

By default, only admins can query system and Customer Service Management (CSM) tables. To integrate using a non-admin user, you must explicitly grant table-level permissions for the data your integration will access.

Create a Custom Role

1. Navigate to All → User Administration → Roles → New

2. Fill out:

   • Name/Suffix: integration_role (or any custom name)

   • Description: Custom role for non-admin API access

3. Click Save

You’ll see a generated name like:

x_<instance_prefix>_integration_role

This role will be used in all ACLs and assigned to your integration user.

Create a Non-Admin Integration User

If the integration user doesn’t exist yet:

1. Go to All → User Administration → Users → New

2. Fill out:

   • User ID: integration_user

   • Active: ✅

   • (Optional) Web service access only: enables API-only access

   • (Optional) First name / Last name / Email: recommended

3. Click Set Password to assign a local password (required for Basic Auth)

4. Make sure Password needs reset is unchecked

5. Click Save

Assign the Role to the User

1. Open your integration user record

2. Scroll to Roles → Edit

1. Search for and add the role you created:

   • x_<instance_prefix>_integration_role

2. (Optional) If your integration also needs ITSM data like Incidents or Tasks, add:

   • itil

   • snc_platform_rest_api_access

3. Click Save.

Your user now has a scoped role that will be used for ACL permissions.

Create Custom ACLs (Access Control Rules)

Before creating a Custom ACL, make sure your role is allowed to add Custom ACLs. This can be manually done by Elevating role and enabling the security_admin role for the user:

ServiceNow ACLs define which roles can perform actions on which tables or fields.

You must create one ACL per table (or field) and per operation type (read, write, create).

Go to:
All → System Security → Access Control (ACL) → New

Fill out these fields:

Click Submit.

Add ACLs for Each Required Scope

Each ServiceNow “scope” (table) must have its own ACL.
Below is a complete list of common API endpoints, what they do, and what role or ACL grants access.

Core systems table

Customer service management

ITSM and Task management

Additional Scopes to Include in Custom ACLs

These system tables are frequently queried by integrations. Add read ACLs for your custom role to prevent 403 errors.

User and Role Data

To minimize privilege, use your custom integration role with targeted read ACLs for user-related tables.

Tickets (Tasks, Incidents, Requests, Problems, Cases)

The itil role grants full CRUD access to ITSM “task” tables, including incidents, problems, and catalog tasks.

If integrating with CSM, add sn_customerservice_agent.

Comments (Journal Fields)

Journal fields (comments, work notes) inherit ACLs from their parent record.

If your integration can read/write incidents or tasks, it can usually access related journal fields automatically.

Attachments

Attachments inherit permissions from their parent record.
Your integration user must have read access to one of the parent tables (e.g., incident, task, sn_customerservice_case).

Writing Tickets (POST Access)

To create new tickets via the Table API (POST /api/now/table/<table_name>), your user must have create ACLs or roles granting write access.