ServiceNow

Last Modified on 07/15/2026 1:47 pm EDT

This guide walks a ServiceNow administrator through creating the required ServiceNow roles, creating a dedicated service account, assigning read-only access to the required tables, registering an OAuth 2.0 Client Credentials application, validating Table API access, and entering connection details through the Info-Tech submission flow. It is written for customer administrators and assumes ServiceNow REST Table API extraction via Fivetran.

Reviewed against current public documentation
This version has been aligned to the current ServiceNow Client Credentials workflow, Table API behavior, non-interactive-user guidance, and the current Fivetran ServiceNow connector requirements available as of June 10, 2026.

ABefore you start

You will need:

  • Administrator or delegated administrator access to your ServiceNow instance
  • Permission to manage OAuth inbound integrations and service-account users
  • Permission to grant read access to the required ServiceNow tables
  • A service-account user record (e.g., cioanalytics@yourcompany.com) This only populates the Email field on the ServiceNow user. It is not a login credential, does not require SSO, and does not need to be a working mailbox. The integration authenticates with the OAuth client ID and client secret from Step 4.
  • Access to the Info-Tech portal where the instance URL and OAuth credentials will be entered
    • Check for existing customisations

    Before beginning setup, review your instance for customizations that may affect the integration. Hardened or customized instances can silently block access even when the steps in this guide are followed correctly.

    • ACL default mode — Check the system property glide.sm.default_mode. If set to deny (common on hardened instances), users have no access to any table unless an explicit ACL grants it. If set to allow, users have access unless an ACL denies it. The integration instructions in this guide work under either mode, but understanding which mode your instance uses will help you troubleshoot access issues.
    • REST Table API ACL enforcement — Check the system property glide.rest.table_api.enforce_acl. If this property is false or missing, the Table API does not enforce table ACLs — any authenticated user can read any table via the API regardless of ACL rules. If your security team requires API calls to respect ACLs, set this property to true. The integration works under either setting, but your security team should be aware of the current state.
    • Existing table ACLs — Check whether any of the required tables already have custom ACLs. If an existing ACL uses a Deny Unless condition, it is evaluated before any Allow If ACLs and will block access for the integration role even if a separate Allow If ACL grants it Work with your security team to determine whether the integration role should be added to existing ACLs or whether new ACLs should be created.
    • Existing field-level ACLs — Some hardened instances restrict individual fields (e.g., sys_user.email, phone fields, journal fields) with field-specific ACLs. A table-level ACL alone may grant row access but leave restricted fields blank in the UI. Note that the REST API does not enforce field-level ACLs, so field ACLs primarily affect UI verification in Step 5.
    • Multiple roles on a single ACL — If your existing ACLs list multiple roles, be aware that ServiceNow treats them as OR (any one role grants access), not AND. To enforce AND logic, a script condition is required: gs.hasRole('role1') && gs.hasRole('role2').
    • Class Table Inheritance — Child tables (e.g., incident) inherit ACLs from their parent table (task). Adding a table-level ACL on a child overrides the parent's table ACL, but field ACLs are still inherited from the parent. If you need full ACL control on a child table, you must add both table and field ACLs on the child.

BServiceNow tables required

The integration requires read-only access to the following ServiceNow tables. Required tables are needed for any ServiceNow tenant; conditional tables are only needed if your instance uses the corresponding ITSM module.

Required tables

  • task — parent table (shared ticket fields)
  • incident — incident records
  • sys_user — user / agent reference
  • sys_user_group — assignment group reference
  • sys_user_grmember — group membership bridge
  • sys_user_has_role — user-to-role bridge (agent role names)
  • sys_user_role - role definitions (referenced by sys_user_has_role)
  • sys_choice - field dropdown option values (decodes coded values to labels) 
  • cmn_department — department reference
  • cmn_location — location reference
  • contract_sla — SLA definitions
  • task_sla — SLA instances per task
  • task_time_worked — time-worked / worklog entries per task
  • sys_journal_field — work notes / comments thread

Conditional tables

  • change_request — if Change Management is enabled
  • problem — if Problem Management is enabled
  • sc_request — if Service Catalog is enabled
  • sc_req_item — with sc_request
  • sc_task — with sc_request
  • asmt_assessment_instance — if Assessment & Survey (CSAT) is enabled
  • asmt_metric_result — with asmt_assessment_instance
  • asmt_metric — with asmt_assessment_instance
  • asmt_metric_type — with asmt_assessment_instance
Schema metadata tables (required)

The connector reads these tables during schema discovery to learn which tables and fields exist in your instance. Without access to them, the connection fails before any data is read — typically with an error such as "User does not have access to sys_db_object and/or sys_dictionary tables."

Table Purpose
sys_db_object Table dictionary — lists all tables in the instance
sys_dictionary Field dictionary — lists all fields and their types per table
sys_glide_object Field-type dictionary — maps internal type codes to display types

No create, edit, delete, or write-back permissions are required.

Important — ServiceNow uses Class Table Inheritance
ServiceNow stores ticket data across a parent table (task) and several child tables (incident, change_request, problem, etc.). Shared fields like sys_id, number, state, and opened_at live on the parent. Subclass-specific fields like caller_id, contact_type, category, and close_code live on the child tables only. Both the parent and the relevant child tables must be granted read access for the integration to work correctly — granting access only to task would result in NULL values for many fields.
Steps in this guide
  • 1Create a dedicated read-only role
  • 2Grant table-level read ACLs to the role
  • 3Create a dedicated service-account user
  • 4Register an OAuth 2.0 Client Credentials application
  • 5Verify the OAuth credentials work
  • 6Enter credentials in the Info-Tech portal
Step 1Create a dedicated read-only role
All > System Security > Users and Groups > Roles > New

Create a dedicated role rather than reusing a broad built-in role. This keeps the integration's permissions scoped, auditable, and easy to revoke without affecting other ServiceNow users.

  1. Open the role list. In the navigator, type roles.list and press Enter, or browse to System Security → Users and Groups → Roles.
  2. Click New. Create a new role.
  3. Name the role clearly. Suggested name: x_cioanalytics_read_only or infotech_cioanalytics_read_only. Follow your organization's naming convention for custom roles. Description: Read-only access for the Info-Tech Customer Data Store integration.
  4. Save the role. Do not add broad inherited roles unless your security team has approved them. Table and field access will be handled in Step 2.
Step 2Grant read-only table access to the role
All > System Security > Access Control (ACL)

ServiceNow Access Control Lists govern record and field access. Grant only the read access needed by the integration. Do not relax existing ACL conditions or grant create, write, or delete access.

Critical — understand how new ACLs interact with existing ones

Adding an ACL for the integration role can affect access for other users depending on how your existing ACLs are structured. Review these rules before creating ACLs:

  • OR logic across ACLs:When multiple ACLs exist for the same table and operation, ServiceNow evaluates them with OR logic — if any ACL passes, access is granted. This means adding an unconditional ACL for the integration role will not restrict other users, but it also means a failing ACL on one rule does not block access if another ACL passes .
  • Deny Unless takes precedence:If any existing ACL on a table uses a Deny Unless condition, it is evaluated first. If the condition is not met, access is denied regardless of any Allow If ACLs — including any new ACL you add for the integration role .
  • Data conditions filter rows:ACLs with data conditions (e.g., active=true) act as row-level filters — users with that ACL see only matching records. Adding an unconditional ACL for a different role on the same table creates OR logic that can negate the filter for users matching the unconditional ACL.
  • Empty ACLs deny all:ServiceNow cannot create an open ACL without a role, condition, or script. An ACL with no role requirement and no conditions denies all access. To grant access to all authenticated users, use script condition gs.isLoggedIn() .

If you are unsure how your existing ACLs are structured, work with your ServiceNow security team before proceeding.

  1. Open the ACL list. In the navigator, type sys_security_acl.list and press Enter.
  2. For each required table, create or update a record ACL with these values, following your organization's ACL standards:
    • Type: record
    • Operation: read
    • Name: the table name, such as task, incident, or sys_user
    • Roles: add the dedicated read-only role created in Step 1
  3. Repeat for all required base tables:task, incident, sys_user, sys_user_group, sys_user_grmember, sys_user_has_role, cmn_department, cmn_location, contract_sla, task_sla, task_time_worked, sys_journal_field, sys_choice, sys_user_role and sys_audit_delete.
  4. You must also grant read access to the required schema metadata tables. The connector reads these during schema discovery to learn which tables and fields exist. Without them the connection fails before any data is read, typically with a message such as “User does not have access to sys_db_object and/or sys_dictionary tables.” For each metadata table — sys_db_object (the table dictionary), sys_dictionary (the field dictionary), and sys_glide_object (the field-type dictionary) — create two read ACLs:
    • A record ACL on the table itself — Type record, Operation read, Name sys_db_object (and again for sys_dictionary and sys_glide_object).
    • A field ACL covering all fields — Type record, Operation read, Name sys_db_object.* (and again for sys_dictionary.* and sys_glide_object.*). On hardened instances the table-level ACL alone can still leave fields denied, so the wildcard field ACL is required.
    Add the dedicated read-only role from Step 1 to each of these ACLs. The role is assigned to the integration user in Step 3, and the OAuth application is bound to that same user in Step 4, so no separate role assignment is needed here.
  5. Add conditional tables if used: if your instance uses Change Management, also add change_request; if Problem Management, add problem; if Service Catalog, add sc_request, sc_req_item, and sc_task; if the Assessment & Survey (CSAT) module is in use, add asmt_assessment_instance, asmt_metric_result, asmt_metric, and asmt_metric_type.
  6. Check field-level ACLs. Some hardened instances restrict fields such as sys_user.email, phone fields, or journal fields. If field-level ACLs block required fields, grant read access only to the specific fields needed by this guide.Note: field-level ACLs are enforced in the UI only — the REST API returns all field values if the table-level ACL passes This means field ACL issues may not surface during API testing in Step 5 but could affect UI-based verification.
  7. Do not grant write, create, or delete operations. The integration is read-only.
  8. Alternative: assigning a broad role such as itil may be simpler but grants more access than required. Use this only if your security team approves the broader permission model.
Step 3Create a dedicated non-interactive service-account user
All > User Administration > Users > New

Create a service account whose only purpose is API access for this integration. A dedicated non-interactive account avoids tying the connection to a human user and supports clean deactivation if access must be revoked.

  1. Open the user list. In the navigator, type sys_user.list and press Enter.
  2. Click New.
  3. Fill in user details. Suggested values:
    • User ID:cioanalytics
    • First name:CIOAnalytics
    • Last name:Integration
    • Email:cioanalytics@yourcompany.com
    • Active: checked
    • Identity type:Machine — marks the account as a non-interactive machine identity rather than a person.
    • Time zone:GMT— NOTE: YOU MUST SELECT GMT (not your time zone) as this is the time zone our ETL processes the data in.
  4. Save the user.
  5. Assign the read-only role. Open the user record, scroll to the Roles related list, click Edit, and add the dedicated read-only role from Step 1.
  6. Also add the personalize_dictionary role  - Note: this is an edit role
    7. This role is required for schema discovery. Fivetran needs to read ServiceNow's table and field definitions — which tables and fields exist, and how they're structured — before it can extract data into Infotech's database. ServiceNow appears to gate this read activity behind personalize_dictionary, which may also carry broader write capability to dictionary metadata such as sys_dictionary, even though the connector does not write to ServiceNow.

    Your team will enter the ServiceNow credentials directly into Fivetran's authorization flow; Info-Tech will not receive, store, or handle them. This authorizes ServiceNow only as a source — it does not configure ServiceNow as a destination or create any writeback path from Fivetran or any Info-Tech system.

    Consistent with that, Info-Tech will not create, update, delete, or modify any ServiceNow records, configuration, dictionary entries, fields, tables, or business data. The role is required only so the connector can complete schema discovery and read-only extraction.

  7. Set and store a strong password if your instance requires one. The OAuth Client Credentials token request uses the OAuth client ID and client secret. However, some downstream connector configurations may also require the service-account username and password. Store the password securely and enter it only through the approved Info-Tech submission flow if the final portal requires it.

Step 4Register an OAuth 2.0 Client Credentials application
All > System OAuth > Application Registry > New

Use OAuth 2.0 Client Credentials Grant for this trusted, server-side integration. This flow lets the integration request an access token using a client ID and client secret, without an interactive user login. Newer instances may expose the same setup through Machine Identity Console → Inbound integrations.

  1. Choose the setup path available in your instance. Many instances use System OAuth → Application Registry. Newer instances may expose the same inbound OAuth setup through Machine Identity Console → Inbound integrations.
  2. Create the OAuth client. If using Application Registry, click New and select Create an OAuth API endpoint for external clients.
  3. Name the application. Suggested name: Info-Tech CIOAnalytics.
  4. Set the grant type. Set Default Grant Type or Grant Type to Client Credentials. Do not enable Authorization Code or OIDC-specific options for this integration.
  5. Enable the inbound Client Credentials grant for the instance. ServiceNow gates the inbound Client Credentials flow behind a system property that is off by default. If it is not enabled, the token request in Step 5 will fail even when the OAuth client is configured correctly. In the navigator, type sys_properties.list and press Enter, then search for glide.oauth.inbound.client.credential.grant_type.enabled. If the property exists, set its Value to true. If it does not exist, click New and create it with Name glide.oauth.inbound.client.credential.grant_type.enabled, Type true | false, and Value true. This typically requires the admin role.
  6. Bind the OAuth client to the service account. Navigate to All > System OAuth > Application Registry, then open the OAuth application you just created (e.g., Info-Tech CIOAnalytics). This step links the OAuth application to the cioanalytics service account so that tokens minted by this client inherit the service account's roles and ACL permissions.

    On the OAuth application form, locate the OAuth Application User field (some instances label it simply User). Set it to the cioanalytics service account created in Step 3.

    If the OAuth Application User or Default Grant Type fields are not visible on the form:

    1. Right-click the form header bar and select Configure → Form Layout (or use the hamburger menu → Form Layout on newer UI versions).
    2. In the Available list, find OAuth Application User and Default Grant Type.
    3. Move them to the Selected list and position them where appropriate on the form.
    4. Click Save to update the form layout.
    5. The fields will now appear on the OAuth application form. Set OAuth Application User to the cioanalytics service account and confirm Default Grant Type is set to Client Credentials.

    Without this binding, the OAuth token will not carry the service account's roles, and API calls will fail with 403 Forbidden even though the ACLs are correctly configured.

  7. Configure the Auth scope. Scroll to the Auth scope section of the application form. Under Configure auth scopes, set the Auth scope dropdown to useraccount. Leave the Limit authorization to the following APIs field blank. Under Scope validation settings, the Allow access only to APIs in selected scope checkbox will be automatically disabled — this is expected behaviour when the useraccount scope is selected.
  8. Leave Redirect URL blank unless your instance requires a value. Redirect URLs are for browser-based authorization-code flows. This guide uses Client Credentials Grant.
  9. Do not configure refresh tokens for this guide. Client Credentials integrations request new access tokens using the client ID and secret. Refresh-token handling should only be added if your security architecture explicitly requires it.
  10. Save the application. Record the Client ID, securely reveal and record the Client Secret, and keep your ServiceNow instance URL, such as https://yourinstance.service-now.com, for Step 5 and Step 6.
Step 5 — Verify the OAuth credentials and Table API reads

Run a test API call from your machine, Postman, or another approved API client.

Before entering credentials in the Info-Tech submission flow, confirm that the OAuth client can mint an access token and that the service account can read the required ServiceNow tables through the Table API.

5.1 — Mint an access token

Run from a terminal, replacing the placeholders:

curl -X POST "https://yourinstance.service-now.com/oauth_token.do" --header "Content-Type: application/x-www-form-urlencoded" --data-urlencode "grant_type=client_credentials" --data-urlencode "client_id=YOUR_CLIENT_ID" --data-urlencode "client_secret=YOUR_CLIENT_SECRET"

You should receive a JSON response containing an access_token, token_type, and expires_in.

  • If you get invalid_client, confirm the Client ID and Client Secret.
  • If you get unsupported_grant_type or access_denied, confirm the OAuth client is configured for Client Credentials and is bound to the service account.
  • If the response says the property glide.oauth.inbound.client.credential.grant_type.enabled must be defined and set to true, the instance-level Client Credentials grant has not been enabled — set that system property to true as described in Step 4, then retry.
5.2 — Test a basic table read

Using the access token from the previous step:

curl -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -H "Accept: application/json" "https://yourinstance.service-now.com/api/now/table/incident?sysparm_limit=1"

A successful response returns a JSON result array. 401 Unauthorized usually means the token is invalid or expired; 403 Forbidden usually means the service account lacks read access to the requested table or field.

5.3 — Test required table reads - Optional

Confirm each endpoint returns a successful response. An empty result can be acceptable for tables with no records, but authentication and authorisation should still succeed:

/api/now/table/task?sysparm_limit=1
/api/now/table/incident?sysparm_limit=1
/api/now/table/sys_user?sysparm_limit=1
/api/now/table/sys_user_group?sysparm_limit=1
/api/now/table/sys_user_grmember?sysparm_limit=1
/api/now/table/sys_user_has_role?sysparm_limit=1
/api/now/table/sys_user_role?sysparm_limit=1
/api/now/table/sys_choice?sysparm_limit=1
/api/now/table/cmn_department?sysparm_limit=1
/api/now/table/cmn_location?sysparm_limit=1
/api/now/table/contract_sla?sysparm_limit=1
/api/now/table/task_sla?sysparm_limit=1
/api/now/table/task_time_worked?sysparm_limit=1
/api/now/table/sys_journal_field?sysparm_limit=1
/api/now/table/sys_audit_delete?sysparm_limit=1
5.4 — Test the schema metadata tables

These must succeed for schema discovery; a 403 here is the cause of the "User does not have access to sys_db_object and/or sys_dictionary tables" error. Confirm each returns a successful response:

/api/now/table/sys_db_object?sysparm_limit=1
/api/now/table/sys_dictionary?sysparm_limit=1
/api/now/table/sys_glide_object?sysparm_limit=1
5.5 — Test conditional tables if used - Optional

If your instance uses Change Management, Problem Management, Service Catalog, or the Assessment & Survey (CSAT) module, also confirm:

/api/now/table/change_request?sysparm_limit=1
/api/now/table/problem?sysparm_limit=1
/api/now/table/sc_request?sysparm_limit=1
/api/now/table/sc_req_item?sysparm_limit=1
/api/now/table/sc_task?sysparm_limit=1
/api/now/table/asmt_assessment_instance?sysparm_limit=1
/api/now/table/asmt_metric_result?sysparm_limit=1
/api/now/table/asmt_metric?sysparm_limit=1
/api/now/table/asmt_metric_type?sysparm_limit=1
5.6 — Test display and raw values - Optional
curl -H "Authorization: Bearer YOUR_ACCESS_TOKEN" -H "Accept: application/json" "https://yourinstance.service-now.com/api/now/table/contract_sla?sysparm_limit=1&sysparm_display_value=all"

The response should include both raw and display values. This is useful when validating reference fields, choice fields, dates, and SLA duration fields.

Step 6Enter connection details through the Info-Tech submission flow
Info-Tech submission flow — interim guidance until the formal portal is available
The OAuth client secret and any service-account password are sensitive credentials. Do not send them to Info-Tech by email, chat, ticket attachment, or screen share. Use only the approved Info-Tech submission flow.  
Head over to https://us.app.cioanalytics.ai/  
  1. Open the Connections page.
  2. On the IT Service Management (ITSM) row, click Connect Tool.
  3.  In the Connect to ITSM Tool dialog, select ServiceNow from the dropdown.
  4. Click Continue.
  5. Review the notice describing how Info-Tech uses Fivetran to connect to ServiceNow.
  6. Click Continue. This accepts Fivetran's Terms of Service and Privacy Policy and authorizes data extraction from ServiceNow.
  7. Follow the instructions in the Setup Guide panel on the right to fill in the fields on the left.
  8. When every field is complete, click Save & Test.
  9. Wait for the connection test to finish.

After the connection test succeeds, CIO Analytics takes over the rest of the process automatically.

  1. Once Save & Test succeeds, you are returned to CIO Analytics.
  2. Your ServiceNow data syncs automatically for the first time. Depending on how much history is being pulled, the first sync can take anywhere from a few hours to a few days.
  3. Once that first sync completes, an Info-Tech analyst will reach out to you to continue your onboarding. No further action is needed from you in the meantime.
Notes on this document
  • ServiceNow navigation varies by release, role, and enabled experiences. This guide includes both the legacy Application Registry path and the newer Machine Identity Console path where relevant.
  • If your security team requires more granular access, prefer field-level read ACLs and a dedicated custom role over broad built-in roles.
  • Questions about business purpose, data scope, or onboarding sequencing can be directed to your Info-Tech onboarding contact.
Was this article helpful?
Thank you for your feedback!
© Info-Tech Research Group