Integration Service user guide

DELIVERY:

Last updated Feb 19, 2026

ServiceNow authentication

UiPath supports the following authentication types for ServiceNow:

Authentication type	Description	Best for
Basic (username/password)	Direct login with a ServiceNow user over HTTPS Basic authentication.	Simple, non-OAuth setups, perfect for quick POCs
OAuth 2.0 Authorization Code	User logs in to ServiceNow and grants access to an OAuth client configured in ServiceNow.	User-delegated scenarios in production needing strong governance and easy revocation.
OAuth 2.0 Password Grant	Service account username/password plus OAuth client credentials exchanged for tokens.	Service-to-service integrations where OAuth is required but interactive login is not practical.

Basic (username/password)

Connection fields

Field	Description
Site URL	Full ServiceNow instance URL, for example `https://your-instance.service-now.com`.
Username	ServiceNow integration user name.
Password	Password for the integration user.

Common issues

4XX errors

Verify Instance URL, Username, and Password; ensure the account is active and not locked or blocked by IP/login policies.
Check that the user can read sys_db_object , sys_dictionary and has the necessary ACLs on target tables (read/insert/update/delete).
Make sure your ServiceNow instance is not hibernating.

OAuth 2.0 authorization code

This method grants UiPath access by issuing an access token instead of requiring your username and password as connection fields.

Note:

OAuth 2.0 authorization code grant flow is supported only in ServiceNow Istanbul and later versions.
Callback URL for you app should be https://{baseURL}/provisioning_/callback (for example, https://cloud.uipath.com/provisioning_/callback for Automation Cloud). See Set up OAuth for more details.

Connection fields

Field	Description
Site URL	Full ServiceNow instance URL (for example `https://your-instance.service-now.com`).
Client ID	Client ID from the ServiceNow Application Registry OAuth client used by UiPath.
Client secret	Client Secret from the same OAuth client.

Common issues

Redirect URL mismatch or invalid redirect error

Confirm the Redirect URL configured in the ServiceNow OAuth client exactly matches the callback URL shown in UiPath (scheme, host, path, and trailing slash).
Already authenticated in ServiceNow: Accept/Deny page appears instead of the login screen

This behavior is expected when your browser already has an active ServiceNow session. In this case, ServiceNow skips the login screen and directly displays the OAuth consent (Accept/Deny) page.
- If this is the correct account, click Accept to complete the connection.
- If you need to use a different account, sign out of ServiceNow in another browser tab or retry the flow in an incognito/private window, then sign in with the intended user.
When SSO is enabled

In some SSO setups, neither the login screen nor the Accept/Deny consent page appears. ServiceNow assumes the currently authenticated user and proceeds with connection creation, which may then fail due to missing permissions.

In this scenario, use an incognito/private window to ensure you can authenticate with the correct user and required permissions.
Login and consent succeed, but connection creation failed

The authorizing user lacks ACLs on one or more tables used by the connector. Grant read access to metadata (sys_db_object, sys_dictionary) and read/write ACLs to the relevant business tables, then retest.
Connection worked previously but now fails with authentication or token errors

Access or refresh tokens may have expired or been revoked (for example, after password or OAuth client changes). Reopen the connection in UiPath and re-authorize. If problems persist, check whether the ServiceNow OAuth client was modified or removed.

OAuth 2.0 Password

Connection fields

Field	Description
Site URL	Full ServiceNow instance URL.
Username	ServiceNow service account username.
Password	Password for that service account.
Client ID	Client ID from the ServiceNow OAuth client.
Client Secret	Client Secret from the same OAuth client.

Set up OAuth

Complete the Set up OAuth steps in the ServiceNow documentation.

While the documented steps are likely the same across all ServiceNow platform regions, it's recommended that you follow the steps for your specific region in case there are differences.

For reference, the following procedure explains how we setup OAuth for our examples.

Sign in to your ServiceNow instance (e.g., https://<span>dev74293.service-now.com/login</span>)
Go to System Definitions > Plugins and verify the OAuth plug-in Status is set to Active.
Go to System OAuth > Application Registry and select New.
- When asked What kind of OAuth application?, select Create an OAuth API endpoint for external clients.
Enter a Name for your application (e.g. UiPathQuickstart) and select Submit (if successful, you're redirected back to your Application Registries list).
In the Application Registries list, find your new application and select the Name to open the details page.
Select on the lock icon next to Client Secret to show the value.
Take note of the Client Id and Client Secret values.
Type the following redirect URL in its corresponding field: https://{baseURL}/provisioning_/callback (for example, https://cloud.uipath.com/provisioning_/callback for Automation Cloud).

Token lifecycle for OAuth2.0 Authorization code

During connection creation, UiPath redirects the user to ServiceNow; the user logs in and approves the OAuth client. UiPath exchanges the authorization code for an access token and a refresh token, storing them securely. Access tokens are short-lived; UiPath automatically uses the refresh token to obtain new access tokens until the refresh token expires or consent is revoked. If the OAuth client is deleted or tokens are revoked in ServiceNow, the UiPath connection must be re-authorized.

ServiceNow roles and permissions

The following table lists the minimum roles and permissions required for creating a connection and using the ServiceNow connector. The requirements apply to all authentication types.

ServiceNow Table	Operation	Access reason
Tables (`sys_db_object`)	read	The Tables module/table functions as a repository that holds a row corresponding to each table in your ServiceNow instance. It is utilized to compile a list of tables for the purpose of executing actions or triggering events. This is required to load all your tables when using the Select Object dropdown for you CRUD activities. docs image
Dictionary (`sys_dictionary`)	read	This table encompasses data about respective columns of a particular table within your ServiceNow instance. This table is required to load input and output fields when you select a table for carrying out an action.
Choices (`sys_choice`)	read	The Choice table contains values for options that appear in choice lists and also for look ups in our curated activities. Without this the design time look ups in our activities will fail to load.
User `(sys_user)`	read	The Choice table contains translated text for options that appear in choice lists and also for look ups in our curated activities. Without this, design-time user lookups in our activities will fail to load.

Furthermore, the user must also possess the requisite access control for the tables essential to the integration scenario. For instance, if you intend to establish an integration user capable of executing typical ITIL help desk actions (e.g., opening, updating, and closing incidents, problems, changes, and configuration management items), you should assign the itil role.

Creating custom roles

Certain Base system roles, such as admin already encompass access control for these tables. But, if you don't want to assign base system roles and aim to provide only the essential access control required for using the ServiceNow connector, you may consider crafting a custom role with the necessary access permissions.

To grant access exclusively to specific tables or tables not covered by the default base system roles, we recommend the creation of custom roles and the assignment of the appropriate access control as needed.

You must provide the new roles with the access controls listed in the following table in order to utilize the ServiceNow connector/activities. For example, a user without administrator permissions requires the personalize_dictionary role to access the sys_dictionary table.

Table	Type	Operation
Tables (`sys_db_object`)	record	read
Dictionary (`sys_dictionary`)	record	read
Choices (`sys_choice`)	record	read
User `(sys_user)`	record	read
Field classes `(sys_glide_object)`	record	read

Note:

Editing or creating access control is a capability exclusive to a user possessing the security\_admin role. If you have any uncertainties, it is advisable to consult your ServiceNow administrator. You can find additional information in elevated privilege roles.

For carrying out activity or trigger executions, you need to provide other access controls as well.

For instance, if your specific scenario involves initiating a workflow with a ServiceNow incident or creating a ServiceNow incident, the following access controls need to be granted.

Table	Type	Operation
Incident	record	read
Incident	record	write

Add the ServiceNow connection

To create a connection to your ServiceNow instance, you need to perform the following steps:

Select Integration Service from the left rail.
From the Connectors list, select ServiceNow. You can also use the search bar to narrow down the connector.
Select the Connect to ServiceNow button.
Select your preferred authentication type and enter the required credentials.
Select Connect.
Next, enter your ServiceNow username and password. The app asks for your permission to connect to your ServiceNow account and to interact with records. Select Allow.