ServiceNow Data Connector
The BigPanda Unified Data Connector (UDC) syncs data from ServiceNow to provide context and insights for AI Incident Assistant (Biggy), AI Incident Prevention, and AI Detection and Response. Ingested data is securely stored and made available in the IT Knowledge Graph, powering accurate answers, deep analytics, trend analysis, and advanced capabilities.
Not bi-directional and monitoring incident sync
The Data Connector does not enable incident sync and sharing from the BigPanda event monitoring incident feed. See the ServiceNow integration documentation for details on managing incidents with ServiceNow and BigPanda.
Authorization
Use either OAuth2 or basic HTTP auth to configure Unified Data Connector with ServiceNow. OAuth2 is recommended for production environments.
Create the required credentials for your chosen authorization method, then send them to your BigPanda account team who will finish the authorization process.
Time conversion
The Unified Data Connector will convert all date and time fields into UTC. This ensures consistent date handling across different environments and time zones.
The system also automatically combines the date format and time format for complete date/time parsing. (For example, YYYY-MM-DD HH:mm:ss)
Configure UDC with OAuth2
OAuth2 enhances security and ease of use. This methodwon’t store user passwords and automatically refreshes expired tokens.
To get started, configure the application registry on your ServiceNow instance. The steps are the same as the Splunk instructions found on the ServiceNow site. The Client ID and Client Secret should be saved so that you can send these to your BigPanda account team.
Once you’ve completed that step, provide the following credentials to your BigPanda team.
Field | Description |
|---|---|
Instance | The name of your ServiceNow instance. (i.e. |
Client ID | Client ID copied from your ServiceNow application registry. |
Client secret | Client secret copied from your ServiceNow application registry. |
Time zone | Time zone of your ServiceNow instance. (Used for incremental filtering.) |
Configure UDC with HTTP basic auth
If you’re unable to use OAuth2, you can configure HTTP basic authentication to connect your data. We strongly recommend creating a unique user for BigPanda in ServiceNow to clearly track activity and customize permissions.
Field | Description |
|---|---|
Instance | The name of your ServiceNow instance. (i.e. |
Username | Username of the account used to access ServiceNow. |
Password | Password of the account used to access ServiceNow. |
Timezone | Time zone of your ServiceNow instance. (Used for incremental filtering.) |
The BigPanda team will use your ServiceNow credential information to set up the data connector. Certain fields and options are customizable depending upon your organization’s preferences and requirements.
(Optional) Configure mutual TLS certification
The ServiceNow data connector supports Mutual TLS (mTLS) authentication, providing an additional layer of security for organizations that require client certificate verification. You can use this in combination with either OAuth2 or basic HTTP authentication.
To enable mTLS, you must provide the following information to your BigPanda account team:
Parameter | Description |
|---|---|
Certificate | Your client certificate in PEM format |
Key | Your client private key in PEM format |
Use the PEM format below when providing both the certificate and key. Certificates must include the -----BEGIN and -----END markers and each marker must be on its own line.
-----BEGIN CERTIFICATE----- MIIDXTCCAkWgAwIBAgIJAJC1HiIAZAiU... (base64 encoded certificate data) ...AQ8AMIIBCgKCAQEArXk -----END CERTIFICATE-----
On-prem ServiceNow instance authentication
The connector supports both cloud and on-prem ServiceNow instances. When configuring an on-prem instance, your BigPanda account team will set the deployment type appropriately. Provide the on-prem instance URL and confirm whether reverse-proxy or mTLS is required for inbound access.
Sync preferences
Provide the following information about your sync preferences to BigPanda:
Required Configuration
Option | Description |
|---|---|
Mode | Determine whether you’d like to set up an incremental or historical sync. Most organizations will need to use both modes. See the Streaming Modes section for more information. |
Optional Table-level Configuration
Option | Description |
|---|---|
Related Tables | For each table, you can choose to include a related table. For example, if an incident has CIs, you can include the See the Related Tables section below for a list of related tables and join fields. |
Filter | You can apply query filters to specific tables to granularly choose what data is extracted. Each table’s filter is applied independently. Tables without a filter will load all records. Filters use ServiceNow's encoded query syntax with We recommend using ServiceNow's query builder to test filters before adding them to the configuration. See the ServiceNow documentation for more information. |
Fields | Specify the list of fields to include from each table. The connector uses ServiceNow's The fields setting defines which fields to include. All fields listed will be added. To exclude a column, omit it from the inclusion list, or restrict the BigPanda's service account read ACL on that column on the ServiceNow side. |
Filter high volume tables
Tables such as task, ticket,cmdb_ci, and any custom tables that capture all activity on the platform can produce tens of thousands of records per day. Without an explicit filter, the connector will pull every record on every sync.
We strongly recommend scoping these tables to the assignment groups, CI classes, or change windows that are actually relevant to your BigPanda use case. For example, on task or ticket:
assignment_groupSTARTSWITHProd Support^ORassignment_groupSTARTSWITHSRE
Always validate the filter against your live data using the ServiceNow query builder before saving the connector. After updating a filter, ask your BigPanda account team to confirm the new daily record volume against your previous baseline.
Variable table sync rates
All tables within a single connector share the same sync schedule. To run different tables on different interval, configure a separate connector for each schedule group, each with its own table list and frequency. For example, one connector may sync the incident table, and run every 2 minutes. A secondary connector syncs the cmdb_ci table once per hour.
Optional Pipeline Configuration
Option | Description |
|---|---|
Start Date | If you’re setting up a historical sync, provide the date of when you’d like the sync to begin. If no start date is provided, all data will be synced. We recommend syncing one year of data. |
End Date | Used for historical syncs only. Provide an end date to backfill historical syncs. |
Read Replica | ServiceNow supports read replicas through the If you’d like to set this up, provide your replica name. |
Batch size | The |
Timeout | The |
Performance-Related Configuration
Option | Description |
|---|---|
Query Limit | The maximum number of queries that can be sent per minute. The default is 60 queries per minute. |
Rate Limit Timeout (MS) | The timeout period in milliseconds after the query limit has been reached. The default is 1000 ms (1 second). |
Benchmark performance impact of UDC
ServiceNow administrators and procurement teams often ask how much load the Unified Data Connector places on a ServiceNow instance. This section quantifies the load UDC actually generates, compares it to a typical ServiceNow envelope, and shows how your administrator can verify the impact directly on your own instance.
How we measure performance impact
Performance impact comes down to two measurable dimensions:
Load applied - the requests per hour, concurrency, and payload size UDC sends to your ServiceNow instance.
Envelope available - what your ServiceNow subscription tier and configuration allow. Unlike the load applied, the envelope varies per organization.
UDC load numbers are consistent across the customer fleet. The envelope depends entirely on your ServiceNow setup, so the two need to be compared side by side.
ServiceNow envelope scope
Out of the box, ServiceNow does not enforce a hard limit on inbound API throughput. Throughput is bounded by node capacity and APIINT concurrency. Three configuration points typically determine the envelope available to UDC:
Configuration | Where it comes from | Typical range |
|---|---|---|
Inbound REST rate limit rules ( | Optional, set by your ServiceNow administrator. The rule is per user or per role. | The ServiceNow documentation example is 1,000 requests per hour per user, but real-world values range from 500 to 50,000+ depending on the integration profile. |
Transactions Per Hour (TPH) allocation | Contractual, tied to your ServiceNow subscription tier. | Roughly 5,000 (Standard) to 25,000+ (Enterprise). This is the ceiling that procurement and capacity planning teams care about. |
Node capacity and APIINT concurrency | Instance-level, determined by the size and configuration of your ServiceNow instance. | Varies. |
Confirm your envelope before sizing UDC
Ask your ServiceNow administrator which sys_rate_limit_rule entries apply to integration users, and what TPH allocation your subscription tier provides. These two numbers define the envelope that UDC consumption should be compared against.
Check Telemetry and Debug options
If you observe ServiceNow performance impact you suspect is related to BigPanda, first confirm that Telemetry and Debug are disabled in the BigPanda ServiceNow application (these settings are independent of the Unified Data Connector). Most reported performance impact traces back to those settings rather than to UDC traffic. See the BigPanda ServiceNow App configuration page.
Measured UDC load on ServiceNow
The numbers below are wall-clock averages measured across all UDC ServiceNow customers.
Metric | Value |
|---|---|
Median customer request rate | 100 to 200 requests per hour |
Heaviest single ServiceNow instance in the fleet | 683 requests per hour |
Rate-limit (HTTP 429) responses logged against UDC pull traffic | 0, fleet-wide, last 30 days |
Even compared against the conservative 1,000 requests per hour figure cited as an example in ServiceNow documentation, every UDC customer is well below the limit. Typical UDC consumption is in the single-digit to low-teens percent of a typical envelope, leaving plenty of room for your team's other ServiceNow integrations.
Headline numbers
Median UDC usage sits at 100 to 200 requests per hour. Even the single heaviest organization pulls under 700 requests per hour. No rate-limit responses have been logged against UDC pull traffic.
Example production performance impact
The following figures represent an example enterprise customer running UDC in production for roughly 2.5 months. The numbers cover a 30-day window of steady-state operation.
Metric | Value |
|---|---|
Average request rate | 115 requests per hour (wall-clock) |
Total API calls | ~82,000 |
Total records pulled | ~302,000 |
Total data volume | ~5 GB |
This deployment sits well within every common rate-limit configuration and well below the TPH allocation tied to standard ServiceNow subscription tiers.
Verify UDC's footprint on your own instance
Your ServiceNow administrator can confirm UDC's actual load directly on your instance. Two ServiceNow tables hold the relevant data:
Table | What it shows |
|---|---|
| Lists any rate limit rules currently applied to the BigPanda integration user. Use it to confirm exactly which limit, if any, your team has configured for UDC. |
| Records request volume and response status by user, including UDC pull traffic. Use it to measure UDC's request rate and to confirm that no |
To run the check:
In ServiceNow, navigate to System Definition > Rate Limit Rules to review entries in
sys_rate_limit_rule. Filter for any rule that targets the BigPanda integration user or its role.Navigate to the
sys_transaction_logtable and filter on the BigPanda integration user over a 30-day window. Sort by URL or response code to confirm the request mix and that no429responses appear.
Importance of self-verification
Filtering sys_transaction_log by the BigPanda integration user gives you a direct, instance-specific view of UDC's footprint on your own ServiceNow instance. For most administrators and procurement teams, this is more convincing than any benchmark reported externally, and it shows exactly which limit, if any, applies to UDC traffic in your environment.
Data requirements for ServiceNow UDC configuration
To leverage all of the BigPanda features that integrate with ServiceNow, you must ensure that your UDC configuration includes all required tables and fields. You can also configure additional custom tables and fields for added functionality and more robust contextual enrichment.
Required fields
All tables must include specific required fields to be ingested successfully. As long as these minimum requirements are met, you can include as many additional custom fields as you want.
Related tables
In every table, you can choose to include one or more related tables. (For example, if an incident has CIs, you can include the task_ci related table to collect them along with the incident.)
While many related tables are optional, Biggy requires the change_task and task_ci related tables for successful ingestion.
See our documentation on Related Tables for a list of common related tables and their join fields.
Required fields
All ServiceNow tables connected to the Unified Data Connector must include these minimum required fields.
sys_id
sys_created_on
sys_updated_on
sys_created_by
sys_updated_by
Some tables may have additional required or recommended fields, including fields necessary for related tables.
Redacted columns
Non-required fields are able to be individually redacted from a table. This adds additional security to ensure that no sensitive data is included during table syncs.
See the Data Redaction documentation for detailed options on protecting sensitive data.
Required tables for ServiceNow UDC configurations
Some features require more tables than others, but we strongly recommend including all of these core tables for all features. Broader datasets allow BigPanda to provide comprehensive context, better analysis, and more accurate answers.
ServiceNow table | Additional required fields for IA | Additional required fields for IP | Is the table required for ADR functionality? |
|---|---|---|---|
change_request | number | number short_description description state impact urgency priority risk risk_analysis approval approval_history backout_plan justification test_plan change_plan assignment_group assigned_to cmdb_ci business_service start_date (or equivalent) end_date (or equivalent) close_code close_notes closed_at opened_at Any additional field where vital information regarding the risk of a change. | |
change_task | Required as related table change_request |
| |
cmdb_ci | name |
| |
incident | affected_service assigned_to assignment_group brand_category business_duration business_impact caller_id category caused_by close_code close_notes cmdb_ci contact_type impact knowledge location made_sla major_incident_state number opened_by parent_incident priority problem_id reassignment_count reopen_count resolved_at resolved_by short_description state subcategory urgency work_notes x_bip_panda_bigpanda_id | assignment_group business_duration business_impact business_service caused_by ci_additional_info close_notes cmdb_ci comments description impact location number opened_at priority resolution resolved_by short_description technical_details urgency work_notes Any additional field where vital information regarding the scope, impact, or resolution of incidents. | Table required for: Service Desk Correlation Historical Incidents |
kb_knowledge | number |
| |
problem | number |
| |
task_ci | Required as a related table task |
| Table required for: Service Desk Correlation |
Recommended tables for ServiceNow UDC configurations
The following tables are not required for any basic functions, but are highly recommended for improving contextual functions.
ServiceNow table | Additional required fields for Incident Assistant |
|---|---|
sys_attachment |
|
sys_attachment_doc |
position |
task | number |
Custom tables in ServiceNow UDC configurations
Additional and custom tables can be connected to deepen the context and performance of BigPanda features.
Custom tables must include the minimum required fields:
sys_id
sys_created_on
sys_updated_on
sys_created_by
sys_updated_by
Dot Walking Supported
The ServiceNow BigPanda Data Connector natively supports dot walking.