ServiceNow Sample data sets

Sample data is only useful if it exercises the thing you are trying to learn, and the three kinds below each serve a different kind of practice. Building them is a short exercise in itself, and doing that teaches more than downloading somebody else’s file.

Incidents across priorities and states give you something to build reports, dashboards and assignment rules against. A single incident tells you nothing about whether a priority matrix discriminates or whether a list view is readable; two hundred spread across states does.

Users, groups and role assignments are what you need before any access control work. Testing an ACL as an administrator proves nothing, so you need real users with different roles to impersonate, and groups with members to test assignment against.

Configuration items with relationships are the set most people skip and most need. A CMDB of items with no relationships cannot answer an impact question, so practising service mapping, change impact or event correlation requires the relationships to be there.

The route that works for any tabular data, and which is worth doing once as an exercise in its own right.

1. Get a personal developer instance. It is free, it resets after a period of inactivity, and it is the correct place for all of this.
2. Load the file as a data source, which creates a staging table with a column per field.
3. Create a transform map from that staging table to the target table, and set a coalesce field so that reloading updates rather than duplicates.
4. Run the transform and read the import set rows. Rows that failed say why, and this is the most useful part of the exercise.
5. Check the target records, then deliberately reload the same file and confirm the count did not double.

Step five is the point. Loading data is easy; loading it twice without creating a second copy of everything is the skill, and it is the same mechanism every real integration uses.

One warning that matters more than the rest of this page. Do not load configuration items through a plain transform map onto the CI tables.

CIs go through the identification and reconciliation engine, which decides whether an incoming record is something the CMDB already holds and which source is allowed to own each attribute. Bypassing it is the single most common cause of a CMDB full of duplicates, and practising the wrong method on a developer instance is how the wrong method becomes a habit.

Relationships are separate records with a parent, a child and a type, so a CI load and a relationship load are two exercises rather than one. See the CMDB and import sets.

Three rules that cost nothing and save a rebuilt instance.

Never load sample data into anything but a developer instance. Sample users in a production instance are real accounts as far as the platform is concerned.

Capture your work in an update set before you start, so the configuration you build is portable and you can see exactly what you changed. Sample data does not travel in an update set and your transform maps, business rules and views do. See update sets.

Know what you can undo. Deleting imported records is straightforward; unpicking duplicated CIs with relationships attached is not.

Version note: personal developer instances, the import set mechanism and the identification engine are all long standing and stable. What changes between releases is the CI class model and the recommended classes for a given kind of thing, so a CI file written against an older class model may load into classes your instance no longer favours. See data policies and data stream actions.