Thank you for your feedback.
Form temporarily unavailable. Please try again or contact docfeedback@servicenow.com to submit your comments.

Configure third-party data integration for CSM

Log in to subscribe to topics and get notified when content changes.

Configure third-party data integration for CSM

Configure the required components to enable the third-party data integration feature for Agent Workspace for CSM.

Before you begin

Role required: admin

Procedure

  1. Identify the third-party application.
    This application must meet the following requirements:
    • Should have REST or SOAP API endpoints to call to fetch data.
    • Must support OAuth 2.0 – JWT Bearer grant type as a provider.
  2. Set up OAuth 2.0 – JWT Bearer grant type to set up the handshake between the ServiceNow instance and third-party application.
    This step requires admin access for both the ServiceNow instance and the third-party application.
    1. Create a Java Key-Store (JKS) file and extract the public key (.pemfile) from the keystore.
    2. Upload the JKS file in the X.509 Certificate (sys_certificate) table on the ServiceNow instance.
    3. Create a JWT key record using the sys_certificate record and the password used to create the keystore.
    4. Create a JWT provider record using the JWT key created and use it to create an OAuth Entity record with JWT bearer as the grant type.
    5. Configure the claims that need to passed to the third-party application in every request made from the Now Platform to fetch data.
  3. Create a REST message and test the third-party application’s REST endpoint.
  4. Create the remote table on your ServiceNow instance to expose the data from the application through the GlideRecord interface. Then create the remote table script definition to map the data from the third-party table to the remote table.
    1. Use the Transformer APIs in the script definition to map the data from the REST message call onto the remote table.
    2. Configure error messages if the script definition REST API call results in an error. This error is picked up by the form, list, and field elements and is displayed for the end user when an error occurs.
      These error messages distinguish between cases where the response from the third-party application has no data against an error while fetching data from the third-party application.
    3. Configure ACLs on the remote table to provide users and roles with read access to the third-party data.
    4. Configure ACLs to revoke CREATE, WRITE, and DELETE access on the remote table for all users.
  5. Configure the lists, forms, and fields that pull data from the remote table.
    Once the remote table is set up, you can access data using the GlideRecord interface.
    1. Use Agent Workspace components to embed third-party pages and reports in iframes as popups or related items.
    2. Configure UI actions on forms to create deep links to the records in the third-party application.
  6. Perform some lightweight data synchronization prior to using the feature.
    For example, pull in account data from a third-party application using an import set. In the example provided, the Account (customer_account) table has an Account ID column, which is populated with the ID of the account in the third-party application instance. This column is used as the foreign key to pull opportunities for the corresponding account on the third-party application instance.
Feedback