Getting Your ServiceNow Data

Cortex reads ServiceNow data from a relational mirror database (MariaDB, PostgreSQL, or SQL Server). The preferred way to build that mirror is the ServiceNow table mirror planner in Cortex, which copies data from your live instance over the Table API. If you already have a database-level export from ServiceNow (typical for self-hosted or offboarding projects), you can restore it instead and point Cortex at that database.

---

Recommended: ServiceNow table mirror planner

The mirror planner connects to your ServiceNow instance, figures out which tables you need (including metadata and dependencies), creates the target schema, and runs a background copy job. This is the approach we recommend for most customers, including hosted (SaaS) instances, because you do not need direct access to ServiceNow’s underlying database.

Open it from Utilities → ServiceNow table mirror planner in Cortex, or go to /utilities/servicenow-table-planner. You need Cortex admin access and a ServiceNow user with the admin role so the Table API can read dictionary and UI metadata.

Workflow

1. Connection — Enter your instance URL and credentials, or choose a saved ServiceNow API data source. Use Test connection to confirm Table API access.

2. Save data source (optional) — Store the API connection in Cortex (encrypted) for reuse.

3. Select tables — Pick the business tables you want in the archive. Selecting a base table also selects derived tables via sys_db_object.super_class. Use Refresh catalog if you change selections later.

   Recommended tables to select — Start with the objects your teams search most often. The planner’s Run analysis step adds reference, inheritance, and form dependencies on top of your picks; you do not need to manually select every lookup table.

   Category	Tables (logical names)
   ITSM core	incident, change_request, problem, kb_knowledge
   Work notes & tasks	sys_journal_field, task (often added automatically when you select tables that extend task, such as incident)
   Service catalog	sc_request, sc_req_item, sc_task
   People & groups	sys_user, sys_user_group, sys_group
   CMDB (if used)	cmdb_ci, cmdb_ci_service, cmdb_rel_ci
   Customer Service / CSM (if licensed)	interaction, sn_customerservice_case
   Custom data	Any u_* or scoped app tables your teams rely on (names vary by instance)

   Add or remove tables based on what you actually use. Rows marked likely unused in the catalog usually have no data—you can skip them unless you know otherwise. For a first mirror, selecting the ITSM core row plus service catalog and sys_journal_field is a solid baseline; expand to CMDB or CSM tables when those modules matter to your archive.

4. Analyze & export — Click Run analysis. The planner expands your selection to include required metadata, reference tables, inheritance parents, form/related-list dependencies, and attachments. Download the CSV or JSON table list if you want a record of the plan.

5. Archive database — Point at the empty target database using a ServiceNow data source (MariaDB, PostgreSQL, or SQL Server). Create a new connection or reuse an existing archive data source. For multi-node instances, you can add extra Table API base URLs (same credentials).

6. Mirror run — Click Start mirror job. Cortex creates tables (column types from sys_dictionary), copies rows with keyset paging, and downloads attachment payloads into sys_attachment / sys_attachment_doc. Progress survives app restarts.

Monitor the job on the same wizard step or open Utilities → ServiceNow mirror jobs (/utilities/servicenow-mirror-jobs) for per-table status, retries, and row-level failures.

When the job completes, configure your ServiceNow database data source in Cortex to use that mirror. The archive UI expects physical table names such as {logical}_archive where applicable; the mirror job follows the same naming rules Cortex uses when browsing.

---

Hosted ServiceNow (SaaS)

Hosted customers usually cannot connect to ServiceNow’s production database directly. ServiceNow does not publish a general-purpose “export my entire database” self-service tool for SaaS tenants. Typical options are:

Approach	When to use
Cortex table mirror planner (above)	Ongoing archive projects; you have admin Table API access to the instance.
ServiceNow support / account team	Offboarding, legal hold, or a one-time full copy when API-based mirroring is not practical. Ask explicitly for a full relational backup of your instance data in a restorable format, and which engine (MariaDB/MySQL, etc.) applies.

---

Alternative: Native database export

If you manage the database (self-hosted ServiceNow, or you received a full backup from ServiceNow), restore it to MariaDB, PostgreSQL, or SQL Server and register it as a ServiceNow data source in Cortex. Use the same engine family when possible so types and identifiers match what Cortex expects.

PostgreSQL

pg_dump -U <db_user> -h <source_host> -F c -b -v -f servicenow.dump <database_name>

pg_restore -U <db_user> -h <target_host> -d <new_database_name> -v servicenow.dump

In pgAdmin: right-click the database → Backup / Restore.

MariaDB / MySQL

ServiceNow platform databases are often MariaDB-compatible.

mysqldump -u <db_user> -p -h <source_host> --single-transaction --routines --triggers <database_name> > servicenow.sql

mysql -u <db_user> -p -h <target_host> <database_name> < servicenow.sql

For very large databases, consider Percona XtraBackup or your DBA’s standard physical backup process instead of a single enormous SQL file.

SQL Server

Use SQL Server Management Studio (Tasks → Back up / Restore) or your usual .bak backup script. Confirm collation and compatibility level with your target server before restore.

Export format

Native exports are relational dumps (.sql, custom-format pg_dump, .bak, or vendor-specific backup files)—not CSV extracts of individual tables. Cortex needs the full table structure plus sys_* metadata tables, not just fact tables.

---

Essential tables for the archive

Cortex needs ServiceNow metadata tables to render lists, forms, labels, and attachments correctly. At minimum, include:

Core metadata

• sys_db_object
• sys_dictionary
• sys_documentation
• sys_ui_list
• sys_ui_list_element
• sys_ui_form
• sys_ui_form_section
• sys_ui_section
• sys_ui_element
• sys_ui_page

Attachments

• sys_attachment
• sys_attachment_doc

Your data

• Every business table you want searchable in the archive (for example incident, task, sc_req_item, and any custom tables).

The mirror planner’s Run analysis step adds these automatically and walks reference fields, inheritance (super_class), forms, and related lists so dependent tables are not missed. If you export manually, include all sys_* tables when possible—Cortex mirror jobs also merge every sys_* table listed in sys_db_object for completeness.

If you must trim a very large export, do not drop the metadata list above, and keep parent tables for any table that extends another (for example task when you include incident).

---

Attachments

ServiceNow stores attachment metadata in sys_attachment and file content in sys_attachment_doc (chunked Base64 rows). They live in the database, not in a separate filesystem share like some other products.

• The table mirror planner downloads file bytes over the Table API and writes both tables into your mirror.
• A raw database backup already includes those tables if the backup is complete; verify row counts for large attachment volumes.

Very large attachments can dominate mirror time and disk space. Plan extra storage and expect the attachment phase to run after main table copies finish.

---

Size, format, and licensing

• Size — Full instances can be terabytes. API mirroring is subject to Table API rate limits and may run for days; database dumps need corresponding restore disk and bandwidth.
• Format — Cortex expects a normal relational schema (tables and columns), not JSON/XML instance exports unless you have already loaded them into a supported database.
• Licensing — Your ServiceNow subscription and data-processing agreements govern whether you may copy instance data to an external archive. Hosted customers should confirm offboarding and backup terms with ServiceNow; self-hosted customers should follow their internal retention policy.

---

Time-sensitive situations

Plan exports before instance decommission or license end. After a hosted instance is shut down, Table API access and support-requested backups may no longer be available. Retention windows vary by contract—do not assume ServiceNow will keep a restorable backup indefinitely after termination.

For in-flight mirror jobs, use the mirror jobs dashboard to resume interrupted jobs rather than starting duplicate copies against the same database.

---

Common gotchas

Missing admin Table API access — Without sufficient roles, catalog load or dictionary reads fail. Use an account with admin (or equivalent Table API scope) for the planner connection.

Incomplete metadata — Exporting only incident (or similar) without sys_dictionary / UI tables produces a database that loads rows but cannot render forms or lists correctly.

Inheritance — Tables that extend task or other parents need those parent tables (and columns) in the mirror. The planner selects derived tables when you pick a base table; manual exports must do the same.

Large catalog refresh — The Select tables step queries sys_db_object and sys_table_size; instances with tens of thousands of tables can take a long time on first load.

Rate limiting — SaaS instances may throttle Table API traffic during mirror runs. Failures are recorded per table on the mirror jobs page; resume after addressing limits rather than deleting the target database.

Engine mismatch — Restoring a MariaDB dump into PostgreSQL (or vice versa) without a proper migration step will not work. Match engine family to your Cortex ServiceNow data source.

Stale exports — Database dumps taken while the instance is under heavy write load can be inconsistent unless you use snapshot-capable backup tools or quiesce writes per your DBA’s guidance.

---

Sending the file

Once you have your export, if it is too large to send as an email attachment, we can work with a OneDrive or Google Drive link, or we recommend Our Box Drive. Contact us if you need to arrange a more secure transfer method.