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 clears that module's tables first, so importing is repeatable: run it again and you get a clean copy, not duplicates.
• 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.

---

• 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.