How do you export ServiceNow data for an AI data license?
ServiceNow is where many IT teams keep the written history of what broke, who asked for what and how it was fixed. That history sits in tables, and a table can be pulled out in several ways, each with different limits. This guide covers where the records live, which route returns which part, and what has to come out before anything is shared.
What a ServiceNow instance usually holds
| Incidents | A reported fault, the work notes added while it was handled, and the resolution text. The pairing of symptom and fix is the layer AI labs look for. |
| Requests and request items | Standard asks such as access or equipment, with their approvals and fulfilment steps. |
| Change records | Planned changes with the reason, risk notes, approvals and the outcome after the change. |
| Knowledge articles | Written how-to and fix articles that the service desk publishes to staff or customers. |
| Problem records | Root-cause write-ups that link several incidents to one underlying cause. |
| Archived records | Closed records that an archive rule moved into separate archive tables on the same instance. |
How records leave ServiceNow, route by route
| Tool | What an export gives you | What is missing or needs an admin |
|---|---|---|
| List export (Excel, CSV, JSON, PDF, Google Sheets) | The records and the columns shown in the list. The documentation says these formats are open to all users, subject to what the user's roles let them see. | Only the displayed fields are exported, so work notes and comments must be added as columns first. CSV defaults to Windows-1252 encoding, and the documentation names a property that switches it to UTF-8. |
| XML export from a list or form | All data for a table or a single record, as the documentation describes it. | Needs the admin role. The documentation notes that image field data is not preserved in an XML export. |
| Export sets | A scheduled or repeated pull of table data for bulk use. | Needs the export set admin or admin role. We did not read the full setup steps, so check the current page for your release. |
| Table API (REST) | Any table that the calling account may read, in pages, with filters. A developer can pull work notes, comments and reference values in one job. | The reference lists a default page size and warns that very large page sizes can hurt performance. The account used needs read access to every table involved, and the instance owner sets the limits that apply. |
| Archive tables (ar_ prefix) | Closed records that archive rules moved aside, for example ar_incident. They stay on the same instance until a destroy rule removes them. | The documentation we read does not say how long they are kept by default. Live exports of the main table will not include them. |
Tool names belong to their owners and are used only to say where records usually live. Export features change by plan and version, so check the current rules for your account.
Finding the records and who has to be involved
Start from the table names: incident, sc_request, sc_req_item, change_request, problem and kb_knowledge are the usual ones. An instance with custom applications may keep similar history in tables with a u_ or x_ prefix, and those need an owner who knows the build.
A normal list export can be run by many users, but the XML route and export sets need elevated roles, and the Table API needs a service account with read rights. Decide early who holds that access, and keep it read-only. The vendor's pages change by release, so check the current rules for your instance.
Counts to report for the service desk, with the dates they cover
Report incidents, requests and changes as separate counts, then knowledge articles as a fourth count. Each list view shows a row total for its current filter, which makes a quick estimate. Mark each figure as verified if a person read it from the filtered list, or estimated if it came from memory or a dashboard.
Note the oldest and newest opened date for each table, and add a separate count for the archive tables, because main-table counts will not include them. Say whether work notes were turned on for the whole period, since a record without notes holds much less.
What to clean before IT records leave
Incident text names employees and customers, and it often carries machine names, IP addresses, usernames and pasted error logs. Passwords and tokens appear in work notes more often than teams expect. Each of these is removed or replaced with a de-identified label before a sample goes anywhere.
Some knowledge articles were copied from a software vendor's manual or bought from a content provider. Those are not the company's to license, so they are left out of the license unless the contract says otherwise. General information, not legal advice: counsel can confirm which articles qualify.
What stays out of a ServiceNow set
| Credentials and secrets | Passwords, API keys and tokens pasted into work notes. A record where they cannot be removed with confidence is not licensed. |
| Employee and customer identifiers | Names, email addresses, phone numbers, user IDs and device owners, replaced with de-identified labels or removed. |
| Network and security detail | Internal host names, address ranges and security incident files that would describe how the company is built or attacked. |
| Vendor-licensed content | Knowledge articles taken from a vendor manual or a paid content feed. |
Choosing a sample from a service desk
A regional hospital supplier has run its service desk on ServiceNow for many years and has closed most old incidents into archive tables. An admin lists the row counts for incident, change and knowledge tables and for the matching archive tables, and marks each as read from the screen. A developer pulls resolved incidents with work notes through the Table API using a read-only account. The cleaned sample drops credentials, replaces staff names with de-identified labels and leaves out two articles copied from a vendor manual. The owner reads a sample of the cleaned records and decides whether it goes forward.
Questions owners ask about this
Can a normal list export carry the work notes?
Only if the notes are added as columns in the list first, because the documentation says list exports include the displayed fields. Long histories are easier to pull through the API.
Do archived incidents show up in the usual incident list?
They are moved into separate archive tables, so the live list does not hold them. Ask the admin to count and export those tables on their own.
Is there a published cap on how many rows one export may hold?
The export page we read did not state a row limit. The Table API reference gives a default page size, so check your own instance and plan before promising a total.
Who owns the data inside the instance?
The company usually holds its own records, but the subscription agreement is the document to read. Ask counsel whether it limits how exported data may be used.
Didn't find your question? Ask us directly.
Sources
The vendor's own pages this guide draws on. Some help centers did not open for us, and where a step rests on a summary and not the page itself, the guide says so. Menus and limits change by plan and version, so check the current pages for your account.
Keep reading
Related kinds of records
- Support tickets: The whole thread, wrong guesses included, with customers replaced by stand-ins.
- Project and task history: Jira, Asana, Linear, Monday, Trello, ClickUp and Airtable comments and status changes, not task titles.
- SOPs and knowledge bases: Procedures with their edit history and comments; published help articles add nothing.
- Jira data export: How to get issues with their comments and links out of Jira, and the secrets to remove first.