ServiceNow IT Tickets as AI training data
A mature ServiceNow instance records how an IT organisation actually runs: incidents routed between assignment groups, changes approved by a CAB, problems traced back to a root cause. That end-to-end trail of decisions and outcomes is the kind of workflow data AI developers find hard to source. Momentra helps companies assess whether their ITSM history qualifies and, if it does, license or sell a de-identified version of it.
Can ServiceNow IT Tickets be used as AI training data?
ServiceNow IT tickets can be licensed or sold as de-identified AI training data. Incidents with work notes and resolution codes, change requests with CAB approvals and backout plans, and problem records linked to known errors are the most valuable parts. Work notes in sys_journal_field must be exported deliberately, and caller names, hostnames, IPs and CMDB item names are replaced.
No files needed upfront. We sign an NDA before reviewing any sample.
What can be included
You choose the scope. These are the parts of ServiceNow IT Tickets that are typically most useful.
- ✓Incident records (INC) with short description, category, priority, assignment group, work notes and resolution code
- ✓Change requests (CHG) with risk assessments, implementation and backout plans, and CAB approval records
- ✓Problem records and known error articles linked back to the incidents that triggered them
- ✓Service catalog requested items (RITM) and catalog tasks showing how fulfilment was split across teams
- ✓Knowledge base articles (kb_knowledge) and their version history
- ✓Audit and journal history (sys_audit, sys_journal_field) showing state changes, reassignments and SLA timings
Why AI labs value it
Routing decisions with a clear answer
Each reassignment from one assignment group to another shows a triage decision, and the group that finally resolved the ticket is the label. Models learning IT triage need exactly these corrected routing paths, not just the final category.
Change management reasoning
Change requests capture why a change was proposed, how risky it was judged, what the rollback plan was and whether it succeeded. Few public sources show this planning-to-outcome chain for real infrastructure work.
Root cause linked to symptoms
When incidents are linked to a problem record and a known error, the data connects what users reported with what was actually broken. That link is useful for training agents that diagnose rather than just categorise.
Verifiable outcomes
Close codes, reopen counts and SLA met or breached flags give an objective signal of whether a resolution worked, which is what makes ticket data useful for evaluation as well as training.
How it is scoped, exported and anonymized
Pick tables and time ranges
Scoping usually starts with the incident, change_request, problem, sc_req_item and kb_knowledge tables over a defined date range. Security incident (SecOps) and HR Service Delivery cases are typically left out unless you decide otherwise.
Export with journals intact
Records can be pulled through the Table API, XML exports or scheduled reports, but work notes and comments live in sys_journal_field and need to be exported alongside the parent records so the conversation stays attached to each ticket.
De-identify people and infrastructure
Caller and assignee references (sys_user), email addresses, phone numbers, hostnames, IP addresses and CMDB configuration item names that reveal internal systems are detected and replaced. Credentials or tokens pasted into work notes are found and removed before any further use.
How a partnership begins
Share Basic Information
Share only your contact, company, industry, and partnership interests—no raw data required.
Initial Value Assessment
We discuss the data type, completeness, scarcity, and the tasks it could support.
Define the NDA and Boundaries
Before reviewing any sample, we define confidentiality, permitted use, retention, and security requirements.
Receive an Offer and Begin the Partnership
We provide a purchase proposal and contract, then support de-identification and secure data transfer.
Frequently asked questions
- Our instance has many custom tables and fields. Is that a problem?
- Not usually. Custom tables often hold the most specific workflow data. During the value assessment we look at what each custom table represents and agree which ones are in scope.
- Can CMDB data be included?
- The relationships between configuration items can add useful context to incidents and changes, but CI names, IP ranges and hostnames are sensitive. If CMDB data is included, it is generalised or pseudonymised so it no longer maps to your real environment.
- Do you need access to our ServiceNow instance?
- No access is needed to start. The first steps are a conversation and an NDA. How and when data is transferred is agreed in the signed contract, and you decide what goes into the export.
- Are tickets raised by our customers treated differently from internal IT tickets?
- Yes. Customer-facing tickets may be covered by your customer agreements and contain more personal data, so they are reviewed separately. Some companies choose to include only internal IT tickets.
Related
Let's talk about your ServiceNow IT Tickets.
Share only the essential details. No files are required at this stage.
Contact the Momentra team