ServiceNow Connector

Note: Searching through attachments is not supported.

​

Prerequisites

• Admin access to your ServiceNow instance.
• If using OAuth 2.0: an OAuth endpoint configured in ServiceNow (see Step 1).
• If using webhook integration: the Search AI connector must be configured and connected first.

​

Step 1: Configure an OAuth Endpoint in ServiceNow

• JP Region: https://jp-bots-idp.kore.ai/workflows/callback
• DE Region: https://de-bots-idp.kore.ai/workflows/callback
• Production: https://idp.kore.com/workflows/callback

​

Step 2: Configure the ServiceNow Connector in Search AI

1. Select the ServiceNow connector from the list of available connectors.
2. Go to the Authorization tab and provide the following details.

3. Click Connect to authorize.
4. Go to the Configurations tab and click Sync Now to begin ingesting content.

Note: Only articles within their validity date are ingested. Articles past their Valid To date are excluded.

​

Webhook Integration for Real-Time Sync

​

Architecture

1. Script Include — A reusable script (SearchAIWebhookHandler) that handles webhook POST requests to Search AI.
2. Business Rules — Per-table rules that trigger the Script Include on data changes.

​

Benefits

• Changes in ServiceNow are immediately reflected in Search AI.
• Eliminates the need for frequent full syncs.
• Only changed records are processed, reducing system load.
• Users always see the most current information.

​

Configure Webhook Integration in ServiceNow

var <<CommonWebhookSender>> = Class.create();
<<CommonWebhookSender>>.prototype = {
  initialize: function () {},

  send: function (record, action) {
    try {
      var endpoint = 'https://<domain>/api/1.1/webhook/<streamId>/connector-Id';

      var TOKEN = 'b59aebc4-xxx-xxx';

      var payload = {
        source: 'servicenow',
        object: record.getTableName(),
        action: action,
        sys_id: record.sys_id.toString(),
        number: record.number ? record.number.toString() : '',
        knowledge_base_name: record.kb_knowledge_base
          ? record.kb_knowledge_base.getDisplayValue()
          : ''
      };

      var r = new sn_ws.RESTMessageV2();
      r.setHttpMethod('POST');
      r.setEndpoint(endpoint);
      r.setRequestHeader('Content-Type', 'application/json');

      r.setRequestHeader('X-Webhook-Token', TOKEN);

      r.setRequestBody(JSON.stringify(payload));

      var response = r.execute();
      gs.info('Webhook sent. Status: ' + response.getStatusCode());

    } catch (e) {
      gs.error('Webhook error: ' + e.message);
    }
  },

  type: '<<CommonWebhookSender>>'
};

​

How Webhook Sync Works

1. The payload is validated using the authentication token.
2. Existing ServiceNow connector credentials are used to fetch the latest version of the referenced entity.
3. The index is updated based on the operation:
   • Insert/Update — Document is created or updated in the index.
   • Delete — Corresponding content is removed from the index.
4. The sync is logged in the webhook sync records.

​

Advanced Filters

1. Go to the Manage Content tab and select Ingest filtered content.
2. Click Edit configuration to open the Ingestion Filters page.
3. Use the Parameter, Operator, and Value fields to define a filter. Commonly used parameters appear in the dropdown. For the complete list, refer to the ServiceNow developer reference.

• Multiple rules — Define one or more rules. Content matching any rule is ingested (logical OR). Example — select articles matching any sys ID from a list:
• Multiple conditions — Each rule can have one or more conditions joined by logical AND. Content is selected only when all conditions are satisfied. Example — select published articles with a specific sys ID:

• Insert/Update — Document is created or updated in the Search AI index.
• Delete — Corresponding content is removed from the index.

​

RACL Support

​

Knowledge Articles

1. Owners of the knowledge base
2. Managers of the knowledge base
3. User Criteria with Can Read or Can Contribute permissions

• Owners — Added directly to the sys_racl field.
• Managers — Added directly to the sys_racl field.
• Individual users listed under each User Criteria with Can Read or Can Contribute permissions.

"sourceAcl": [
     "25431493ff4221009b20ffffffffffe0",
     "John@example.com"
]

​

Incidents

1. Role-based access — Users with Base System Roles such as itil or itil_admin have access to incidents. A Permission Entity is created per role; associate users using the Permission Entity APIs.
2. ACL-based access — Users with access to the Incident Table (incident) through ACL configuration. A Permission Entity is created per ACL rule.
3. Assignment group-based access — Members of the incident’s assignment group automatically have access. A Permission Entity is created using the group ID.
4. Incident field-based access — Users linked to the incident through specific fields (Creator, Caller, Watch List) are added to sys_racl by email ID.

​

Catalog Items

1. Role-based access — Roles assigned to the catalog item determine access. A Permission Entity is created using the role ID.
2. ACL-based access — Users with access to the Catalog Items Table through ACL configuration. A Permission Entity is created per ACL rule.
3. User Criteria — User criteria defined for the catalog item specify access. A Permission Entity is created using the user criteria ID.

​

Limitations

​

Related Topics

• Access Control in Search AI
• Permission Entity APIs
• Content Sources