ServiceNow

Sync data from your warehouse to ServiceNow tables via the Table API. Keep your incidents, users, configuration items, and any other ServiceNow records up to date with your latest customer and operational data.

Prerequisites

• A ServiceNow instance with an active subscription
• A user account with API access and appropriate table permissions
• Your instance URL (e.g., https://mycompany.service-now.com)

Permissions

The authenticated user must have:

• REST API access enabled (the snc_platform_rest_api_access role or equivalent)
• Read/Write permissions on the target table (e.g., itil role for incident management, personalize role for sys_user updates)
• If syncing to CMDB tables, the itil or asset role is typically required

Authentication

ServiceNow uses Basic Authentication with a username and password.

1. Navigate to Destinations in the Zeotap sidebar
2. Click Add Destination and select ServiceNow
3. Enter your ServiceNow Username and Password
4. These credentials are stored securely and never exposed in the UI after saving

For production use, create a dedicated integration user with only the permissions needed for your target tables. Avoid using personal admin accounts.

Configuration

Target Settings

Common Table Names

Use the internal table name (not the display label) as shown in the ServiceNow Table API documentation.

Supported Operations

Sync Modes

Audience Sync Modes

ServiceNow does not have a native list or audience membership concept, so audience sync modes are not supported.

Features

• Field Mapping: Yes — map your warehouse columns to any ServiceNow table field
• Schema Introspection: No — configure field mappings manually based on your target table’s structure

Default Destination Fields

These common ServiceNow fields appear as suggestions in the field mapping editor:

How It Works

1. Record mapping: Zeotap maps each warehouse row to a ServiceNow table record using your configured field mappings
2. API calls: Each record is sent individually via the ServiceNow Table API:
   • Insert: POST /api/now/table/{table_name}
   • Update: PATCH /api/now/table/{table_name}/{sys_id} (partial update — only mapped fields are modified)
   • Upsert: Uses PATCH if a sys_id primary key is available, otherwise falls back to POST
3. Retry logic: Transient failures (HTTP 429 rate limits, 5xx server errors) are retried with exponential backoff (up to 3 retries per request)
4. Progress tracking: Rows are processed in chunks of 50 with intermediate progress logging

Batch Size

The ServiceNow Table API processes one record per request. Zeotap handles the batching internally, sending records sequentially with automatic retry and error tracking for each individual record.

Rate Limits

ServiceNow enforces rate limits that vary by instance and subscription tier:

• Default: Typically ~1,000 requests per hour (configurable per instance)
• Rate limit response: HTTP 429 with a Retry-After header
• Zeotap behavior: Automatically respects Retry-After headers and applies exponential backoff

If you experience frequent rate limiting, consider:

• Increasing your instance’s rate limit in System Web Services > REST API Rate Limiting
• Reducing sync frequency
• Syncing smaller audience segments

Best Practices

• Use a dedicated integration user with minimal required permissions rather than a personal admin account
• Map the sys_id field as the primary key for upsert and update operations to avoid duplicate records
• Test with a small batch before running a full sync to verify field mappings and permissions
• Use upsert mode when you want to create new records and update existing ones in a single sync
• Monitor sync results in the Zeotap sync run history to catch mapping errors early

Troubleshooting

Authentication failed: invalid username or password

Verify that the username and password are correct. Ensure the user account is active and not locked. Check that the user has the snc_platform_rest_api_access role.

ServiceNow API returned error 403

The authenticated user lacks permissions on the target table. Add the appropriate role (e.g., itil for incident, personalize for sys_user) to the integration user.

Update requires a sys_id primary key

When using Update sync mode, each row must have a sys_id value mapped as the primary key. Without it, ServiceNow cannot identify which record to update. Switch to Upsert mode if some rows may not have a sys_id.

Record not found (404) during update

The sys_id provided does not match any existing record in the target table. Verify that the primary key mapping is correct and that the records exist in ServiceNow.

Instance URL validation failed

The instance URL must match the pattern https://*.service-now.com. Do not include trailing slashes or paths. Example: https://mycompany.service-now.com.

Rate limited (HTTP 429)

Your sync is exceeding the instance’s API rate limit. Zeotap automatically retries with backoff, but persistent rate limiting may require increasing the limit in ServiceNow or reducing sync frequency.

Fields not updating as expected

ServiceNow fields may have business rules, access controls, or read-only restrictions that prevent updates via the API. Check the target table’s dictionary and business rules in the ServiceNow admin console.

Connection timeout

Large syncs may experience timeouts if the ServiceNow instance is under heavy load. Zeotap uses a 120-second timeout per request. If timeouts persist, try syncing during off-peak hours.