ServiceNow protects table records, attachments, and field relationship metadata through comprehensive backup and restore capabilities. This workload provides dependency-aware restore with cross-reference fixup to maintain data integrity across your ServiceNow instance.
What's supported
ServiceNow requirements
- ServiceNow (base URL:
https://<instance>.service-now.com) - Basic authentication (username and password)
- The backup user must have the
rest_api_explorerrole oradminrole for full REST API access - ServiceNow instance must not be in hibernate mode (applies to development instances)
Supported resources and data
ServiceNow protection covers a four-level hierarchy:
- Table — ServiceNow tables including incident, change_request, cmdb_ci, and custom tables
- Record — Individual table records with fields, identified by sys_id
- Attachment — Binary files linked to records (images, PDFs, and other documents)
Additional data backed up with tables:
- Field definitions and data types from sys_dictionary
- Reference field relationships for dependency-aware restore
- Attachment metadata and binary content
Backup and restore capabilities
| Capability | Details |
|---|---|
| Backup levels | Full and incremental backups. Incremental backups use timestamp-based change detection. |
| Incremental change detection | Timestamp field comparison using the sys_updated_on field to identify changed records |
| Backup consistency | Live data only. ServiceNow provides no lock or snapshot API. |
| Restore granularity | Table and attachment level |
| Restore destinations | Same instance or different instance (out of place) |
| Restore method | Three-phase batch restore: PATCH existing records by sys_id, retry 403 errors, POST new records that don't exist |
| Cross-reference fixup | Automatic remapping of reference fields (sys_id pointers) after initial restore to maintain data integrity |
Data flow and storage
Commvault access nodes connect to the ServiceNow Table API endpoint to download backup data. The access node serializes table records as JSON and stores them in the configured backup storage destination. Attachments are downloaded from ServiceNow and stored as separate binary files. Since ServiceNow is a global SaaS service, neither the access node nor the backup storage has regional placement requirements.
What isn't supported
- System tables — Tables with name prefix
sys_are excluded from discovery by default - Domain separation queries — The
sysparm_query_no_domainparameter requires special roles and is not used by default
Limitations
- Hibernate detection — If a ServiceNow development instance is hibernated and returns HTML instead of JSON, the workload loads field definitions from local cache if available
- Batch API limit — Restore batch size is limited to 150 records per batch
- Workflow state conflicts — Records with active workflows might fail PATCH operations during restore (handled gracefully with logging but not treated as critical failure)
- Server-generated fields excluded from restore — Fields with
sys_prefix (sys_created_on, sys_created_by, sys_updated_on, sys_updated_by, sys_mod_count) are not included in restore payloads because they are server-generated or read-only - Schema intersection during restore — Only fields that exist in the target instance schema are restored; other fields are skipped