FreeITSM can seed itself with realistic sample data so you can evaluate it, test a feature, or take screenshots without hand-building a database first. It lives at System → Demo Data (administrators only).

Use it on an evaluation or fresh install, not a live one. Importing a module replaces that module's data — it clears the relevant tables first (see What "import" does). It is perfect for a demo or a throwaway Docker instance; it is not something to run against a system holding real tickets.

---

Every other module builds on Core Data, so import it first. It seeds the people and structure the rest of the app hangs off:

• 4 analysts (log in with any of them — password demo1234) and 15 end users (portal requesters)
• 5 departments, 5 ticket types, 4 ticket origins
• 2 teams — Service Desk and Escalation Team — wired up as a worked role-based-access example (below)

Then import whichever module areas you want — Tickets, Assets, Knowledge, Changes, Calendar, CMDB, Contracts, and so on — from the cards below Core Data.

---

Since the demo is where people first meet FreeITSM's permissions, Core Data now seeds a realistic RBAC setup rather than a flat one — a pattern you can explore under System → Analysts / Teams / Roles and copy for your own organisation:

	Service Desk	Escalation Team
Members	James Smith, Sarah Williams	Michael Jones, Laura Brown
Module access	a first-line subset — Watchtower, Tickets, Assets, Knowledge, Changes, Problems, Calendar, Morning checks, Service status, Wiki, Tasks, CMDB	all modules
Role	Service Desk — no settings access (use the modules, change no settings)	Escalation Team — every settings capability (full settings access across the app)

Two principles the example is built to demonstrate:

• No demo analyst is an administrator. Administrators bypass all permissions; a realistic desk grants access deliberately instead.
• Access comes from the team, not the person. Each analyst has "all modules" turned off at their own level — what they can reach is granted by the team they're in. That's how a real install should be set up, because it scales: change the team, and everyone in it changes with it.

So an Escalation analyst can open and configure anything; a Service Desk analyst can work in the day-to-day modules but can't change their settings — exactly the split most service desks run.

---

• It reads database/demo-data/<module>.json and writes the rows in one transaction — if anything fails, the whole import rolls back and nothing changes.
• It removes the sample rows it created last time (every row it writes is marked is_demo), so importing is repeatable: run it again and you get a clean copy, not duplicates. Your own rows are never touched.
• Your administrator account is preserved. The import matches it by username and leaves it untouched, so you never lock yourself out.
• Dates are relative to today, so a freshly imported ticket looks like it came in recently, not in 2019.

---

A separate card at the bottom of the page, and the only one with a Remove button. It does not need Core Data. It gives you something to look at for Hyper-V discovery and linking an asset to its configuration item without a real estate:

• Hyper-V - a connection called Demo Hyper-V estate: cluster DEMO-CL01 with nodes DEMO-HV01 and DEMO-HV02, and a standalone host DEMO-HV03 with no usable hardware UUID (so it shows Name only). Three reports an hour apart give it a live migration (DEMO-WEB02), a VM no longer seen (DEMO-OLD01) and an identity change waiting for review (DEMO-BUILD01).
• CMDB - the estate mapped and synced: a CI for the cluster, each host, each VM and the file server role, with is a member of / runs on relationships. A hand-made CI called DEMO-DC01 is left as a same-name match for you to confirm. Payroll (demo) and Intranet (demo) depend on the VMs, so failing a host shows the four grades.
• Assets - two hosts and five VMs. Five are linked to their CIs; DEMO-APP01 and DEMO-NEW01 are not, so you can try Create linked CI (one offers the discovered CI of the same name, the other makes a new one). DEMO-WEB01 and DEMO-WEB01-OLD share a serial and are each linked to a different CI, so merging them from the review list asks which link ends.
• Proxmox, Cloud Director, vCenter - a three-node Proxmox cluster with VMs and containers, a Cloud Director organisation and five vCenter VMs, so Assets -> Servers shows every source side by side. The Proxmox and Cloud Director connections are switched off, so nothing tries to reach them.

Remove takes away exactly this set: everything in its demo CMDB classes (including any CI you made there while trying it), every CI bound to the demo connection, its assets and asset types, links, review cases, and the Proxmox, Cloud Director and vCenter rows. Relationship types and classes it reused from your own CMDB are left alone.

---

• On a throwaway Docker instance (docker compose up), import Core Data and you can log straight in as admin / freeitsm, or as a demo analyst with demo1234.
• If an import ever fails or seems to do nothing, the SSL / HTTPS-style Debug Tools have a dedicated Demo Core Data Import diagnostic (System → Debug tools → D001) that traces exactly what happened.
• Building your own demo data, or adding it for a new module? See the Demo Data — Developer Guide.