Creating and Configuring a ServiceNow System of Record

Prerequisites

  • ServiceNow Account with permissions to create User accounts and grant read access to entities that require synchronization to SGNL
  • Activation of the ServiceNow Read Only Role
    • Note: The ServiceNow Read Only Role should not be the only role granted to the account synchronizing data from ServiceNow - it should be used in conjunction with other roles in order to strip extraneous permissions (Create/Modify/Delete) that are unnecessary for synchronization by SGNL
  • SGNL User Account with Admin privileges to your SGNL Client

Permissions Required

  • SGNL firmly believes in the principle of least privilege, as such - only the access required to achieve your authorization use-cases should be granted.
  • SGNL requires a user account to be created in the ServiceNow instance to be synchronized that has read permissions (see above for configuration of the ServiceNow Read Only Role). Depending on the objects needing to be synchronized the necessarily roles will vary:
    • Users (object: sys_user): Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • snc_internal (granted by default)
    • Groups (object: sys_user_group, sys_user_grmember): Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • rota_manager (for group members)
      • snc_internal (granted by default)
    • Products (object: alm_asset): Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • snc_internal (granted by default)
    • Cases (object: sn_customerservice_case): Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • snc_internal (granted by default)
      • sn_customerservice.case_viewer
    • Customer Accounts (object: customer_account): Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • snc_internal (granted by default)
      • Sn_customerservice.customer_data_viewer
    • All Supported Entities: Requires a user account with roles:
      • snc_platform_rest_api_access
      • snc_read_only
      • rota_manager (for group members)
      • snc_internal (granted by default)
      • sn_customerservice.case_viewer
      • sn_customerservice.customer_data_viewer

Configuring ServiceNow

  1. Log-In to the ServiceNow Instance you’d like to synchronize to SGNL with an account that can create users and manage roles

  2. From the Left Navigation Pane, search or browse for Organization>Users

  3. Create a new user account in ServiceNow that will be used by SGNL to connect to your ServiceNow instance,

    • An example User Id might be sgnl-sync
    • Be sure to note the User Id, you’ll need this to create the SGNL System of Record

    Service Now - New user

  4. Once created, click on the newly created user from the Users list

  5. Select ‘Set Password’ and Generate a strong password for the User

    • Be sure to note the User Id, you’ll need this to create the SGNL System of Record

    Service Now - Generate strong password

  6. scroll down to the Roles tab, and Edit the Users Roles

    Service Now - Edit user roles

  7. Search for the roles you wanted added, select them, and click the right chevron to assign them to the user account

    Service Now - Select roles

  8. Once all required roles are added, Save the changes

Configuring SGNL

  1. Login to the SGNL Console

  2. From the left menu, select Systems of Record

  3. Click “Add System of Record” or “Add”.

  4. The SGNL SoR Catalog will show up on the screen:

    SGNL - Catalog

  5. Click on either “ServiceNow CSM” or “ServiceNow ITSM” which will open up a New System of Record screen. Notice some configuration options pre-populated from the ServiceNow SoR template. Some fields need entire values added, others just tokens (placeholders) updated.

    SGNL - Edit ServiceNow SoR

  6. For Address replace {{Input Required: Instance-Name}} with the subdomain your ServiceNow instance runs on, e.g., acme-corp, if you go to https://acme-corp.service-now.com to login

  7. Under Authentication add values for the following:

    • Username: The User ID of the account you use to login to your ServiceNow instance
    • Password: The password for your ServiceNow account
  8. Under Advanced Settings the template provides you a default Adapter Config. Notice the configuration includes sample filters for each entity (ServiceNow table). Please refer to the Filtering Data Ingested to learn how update or add your own filters.

    SGNL - ServiceNow SoR

  9. Click “Continue” to save your ServiceNow System of Record. You will be taken to the ServiceNow System of Record page.

    SGNL - ServiceNow SoR

  10. All entities and relationships are created as defined in the ServiceNow template. If applicable, you can edit an entity and modify any properties of the entity or the associated attributes. Hover over the entity on the screen above to see the Edit button as shown above.

    SGNL - ServiceNow SoR Edit Entity

  11. You can check the relationships created through the Relationships tab. However, relationships cannot be modified. You will need to delete an existing one, and create a new relationship.

  12. (If applicable) You can also create relationships joining entities and attributes in ServiceNow to entities and attributes in other Systems of Record configured in SGNL. For example, if Account Numbers in your ServiceNow instance are consistent with the Account Numbers in your CRM system, you can create a relationship between the Account Number attribute in the ServiceNow instance and the Account Number attribute in your CRM System of Record. For more information on relationships, please refer to our Relationships page.

  13. Note that synchronization is disabled by default when a new System of Record is created. You can choose to enable synchronization on Entities individually. Hover over the entity to see the Enable Sync button, and click on it.

    SGNL - ServiceNow SoR Enable Sync for Entity

  14. Repeat for all Entities you want to synchronize to SGNL. Finally, Enable synchronization for the System of Record.

    SGNL - ServiceNow SoR Enable Sync for Entity

  15. After some time, SGNL should complete ingesting the data from your ServiceNow instance into the SGNL graph. The number of objects ingested per entity are displayed on the ServiceNow screen. You should then be able to construct policies based on your ServiceNow data and make access evaluation calls to SGNL.

SGNL - ServiceNow SoR Enable Sync for Entity

  1. Once ingestion is complete and ServiceNow data is in the SGNL graph, you can use Data Lens to explore the SGNL graph.

Synchronization Filters

Each pre-configured Entity within a System Of Record has an external ID. For ServiceNow this external ID represents the table name the data came from. Take for example the ServiceNow Incident entity inside SGNL’s System of Record - the corresponding ServiceNow table name and external ID is “incident”

SGNL - ServiceNow SoR - ServiceNow Incident Table

SGNL - ServiceNow SoR - SGNL Incident Entity

To filter the objects for a given ServiceNow table you add a key:value pair to the “filters” object inside the Adapter Config: the key equals the table name (SGNL external ID) and the value a string expression.

{
  "requestTimeoutSeconds": 10,
  "apiVersion": "v2",
  "filters": {
    "incident": "active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30",
    "sys_user": "active=true",
    "change_request": "active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30",
    "change_task": "active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30",
    "problem": "active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30",
    "cmdb_ci_business_app": "active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30",
    "sys_user_group": "active=true"
  }
}

The string expressions used for ServiceNow tables are based on the available fields in the table and ServiceNow’s operators available for filters and queries

For example, the incident filter “active=true^sys_updated_onRELATIVEGT@dayofweek@ago@30” will ingest only active incidents with sys_updated_on greater than 30 days ago (relative to the current date)