Required roles and permissions to connect via Oauth2.0
To utilize the ServiceNow connector/activities, it is necessary to establish the connection with a ServiceNow user that possesses roles with access control to the specified tables.
| 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 you click on the Select Object dropdown for you CRUD activities. |
| 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 the design time user related look ups 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 helpdesk 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.
After the previously mentioned steps have been carried out, it is imperative to provide your new role with the following access controls in order to utilize the ServiceNow connector/activities.
| Table | Type | Operation |
|---|---|---|
| Tables (sys_db_object) | record | read |
| Dictionary (sys_dictionary) | record | read |
| Choices (sys_choice ) | record | read |
| Users(sys_user) | record | read |
Important: 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.
On top of the above, 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 |
ashokkarale
jast1631
Shruthika_r
justindward
Gaurav_Malhotra