Skip to main content
Last updated on

ServiceNow connector FAQs

This page answers frequently asked questions about the ServiceNow connector in Databricks Lakeflow Connect.

General managed connector FAQs​

The answers in Managed connector FAQs apply to all managed connectors in Lakeflow Connect. Keep reading for ServiceNow-specific FAQs.

Connector-specific FAQs​

The answers in this section are specific to the ServiceNow connector.

How does the connector pull data from ServiceNow?​

The ServiceNow connector uses the ServiceNow Table API v2.

Could using the Table API impact the ServiceNow instance?​

Yes. However, the impact depends on the amount of data ingested. For example, it is typically more noticeable in the initial snapshot than during an incremental read.

How does the connector pull data incrementally?​

In order to incrementally ingest a table, the table must have one of the following columns. If none of these columns exists, then the connector snapshots the source table and overwrites the destination table.

  • sys_updated_on
  • sys_created_on
  • sys_archived

Why is my ServiceNow ingestion performance slow?​

Databricks recommends working with your ServiceNow administrator to enable ServiceNow-side indexing on the cursor field. The cursor column is selected from the following list, in order of availability and preference: sys_updated_on (first choice), sys_created_on (second choice), sys_archived (third choice). This is a standard approach for improving performance when ingesting using the ServiceNow APIs. Setting the index allows Databricks to avoid fully scanning the entire sys_updated_on column, which can bottleneck large updates. For instructions, see Create a table index in the ServiceNow documentation.

Databricks also recommends increasing the REST Table API request timeout to more than 60 seconds. This helps to avoid exceeding the transaction limit, which can cause the query to time out. If the issue persists, create a support ticket.

Does the connector require admin permissions?​

No. The connector supports the following options:

  • Admin roles (recommended): Use the admin role and optionally the snc_read_only role. This approach returns the complete table schema in a single API call per table.
  • Least-privilege roles: Use table-level ACLs. This approach requires more API calls for schema discovery. Choose it only if restricting permissions is more important than minimizing API usage.

For a complete list of required permissions, see the source setup.

Why does least-privilege access require more API usage?​

With admin roles, ServiceNow can return the full table schema, including inherited fields, in a single API call.

Without admin roles, the connector must make multiple API calls to discover the schema. Because ServiceNow tables use inheritance, the connector must:

  1. Find the table's parent.
  2. Repeat for each parent table until the root of the hierarchy is reached.
  3. Fetch field definitions for every table in the chain.

The number of API calls scales with the depth of the table's inheritance hierarchy. For example, if a table has a three-layer hierarchy, the connector needs at least three API calls to resolve parent tables plus additional calls to fetch field definitions—compared to a single call with admin access. Schema discovery with least-privilege access happens on each pipeline run, not only during initial setup.