Access rights for Service Now (SNOW) integration to Spectrum
search cancel

Access rights for Service Now (SNOW) integration to Spectrum


Article ID: 254599


Updated On:


CA Spectrum


Please clarify and comment the following concerns of the customer:
According to the customer's assessment these rights are necessary or might be necessary:
Single rights:
Create/Read/Update on:
·         incident
Create/Read on:
·         sys_journal_field
Roles (collection of rights):
·         soap
·         soap_create (included in soap. Not necessary but harmless)
·         soap_delete (included in soap. Not necessary but harmless)
·         soap_ecc (included in soap. Not necessary but harmless)
·         soap_query (included in soap. Not necessary but harmless)
·         soap_query_update (overlaps soap. Not necessary but harmless)
·         soap_script (included in soap. Not necessary but harmless)
·         soap_update (included in soap. Not necessary but harmless)
·         odbc (Only required if the integration uses the ServiceNow ODBC driver)
According to the customer's assessment these rights are NOT necessary or not understandable rights:
Single rights:
·         sys_db_object
     *   This is the list of all tables.
     *   The customer thinks that the integration only needs access to Incident and sys_journal_field tables.
     *   So why should they allow access tot he sys_db_object table?
·         sys_dictionary
     *   This is the list of all table columns.
     *   Unless the integration does not execute an automatic mapping to custom columns (the ServiceNow Administrator created),
          the customer can’t see why this right should be necessary.
·         task
     *   Table that contains several other types of data except Incidents
     *   The Create/Read/Update right on the Incident tabel should be sufficient.
Roles (collection of rights):
·         web_service_admin
     *   Required to create new Webservices in ServiceNow. Not required to consume them.
·         mid_server
     *   The guide says midserver but we guess you mean mid_server.
     *   This role will usually be given to users defined in the ServiceNow Mid Server in order to realize communication between Mid Server and the ServiceNow instance.
·         catalog_admin
     *   Is not related to the Incident module of ServiceNow. Used only for administration of the Service Catalog module.
·         u_journal_entry_user
     *   This role is a Custom Role (as you can see on the prefix “u_”).
          That is to say it does exist in a ServiceNow instance only if an administrator created it and did set some single rights.
     *   The manual does not say which rights would be required.
     *   Based on the name we assume that the rights overlap with the Create/Read right on the sys_journal_field table.


Release : 22.2.x  Spectrum Integration with Service Now


As per Engineering:

The documentation for the servicenow user roles has been prepared based on different issues that have occurred and resolved at different customer environments and all the information may not be needed for every customer but we have documented as it will help to troubleshoot the roles/permissions for the servicenow user.


In general , we give all SOAP roles(both Read & Write) for the incident,task and sys_journal_feild tables(incident table is extending from the task table ) and only READ permission for sys_db_object & sys_dictionary tables will make the integration work most of the times. Please ask the customer to provide these roles and check.


The sys_db_object & sys_dictionary table READ permissions are required for the user as the underlying values of the incident table are reading from its metadata and we are showing them in the customizations page dropdown to map the values and prepare the SOAP payload to send to ServiceNow. We don't need any WRITE permissions on these 2 tables and also we are not storing the metadata anywhere as the dropdown fields values are loading dynamically.



Additional Information

Service Now to Spectrum Integration Docs here