Demo Data
BareBones Ticketing can seed one bounded, synthetic evaluation dataset — a fictional company called Aster Bay Manufacturing — so you can walk the product with realistic records before it touches your real work. This page covers what seeding creates, where the review credentials live, and exactly what a purge removes.
Demo data is for evaluation and rehearsal, not for a system already carrying live work. The tool makes you acknowledge that before it acts, and one of its own warnings says it plainly: "Do not seed or purge demo data on a live production system."
Where it lives
Open Admin Settings, then Demo
Data, or go to /admin/demo-data. Only a System
Administrator can open it, and the whole page is behind step-up like the
other gated admin pages — see Admin settings
and step-up.
The workspace has five tabs: Posture, Seed / purge, Review guide, Tracked records, and Credentials.
One batch at a time
The product tracks demo data as a batch. Only one batch can be active. While one is, seeding again is refused with "Demo data is already seeded. Purge existing demo data before seeding again." Every seeded name carries a short batch token — the departments, users, and services of one batch are distinguishable from any earlier one.
Posture shows the current state: tool posture, active demo batches, tracked record counts, and when the last seed and purge happened. Refresh posture is read-only.
Arming
Seed and purge both refuse to run until you complete the four acknowledgement checkboxes under Demo data arming. They cover, in order: that the seed is for evaluation and release rehearsal only; that seeding creates synthetic users, access rows, departments, tickets, projects, approvals, and external participant data; that purge permanently removes tracked records and eligible dependent records; and — quoted exactly, because it is the one to take personally — "I confirm this operation must not be used to load real customer, vendor, employee, patient, or production data."
Arming is a per-operation acknowledgement, not a stored setting. It grants no other authority.
What seeding creates
One Seed review batch action builds the whole Aster Bay dataset:
| What | Content |
|---|---|
| Departments | Aster Bay IT Operations, Facilities, and Quality, each with its own key |
| People | Seven internal personas and one external participant — see the table below |
| Services | Six, from account access to supplier deviation review and network change, across three service categories |
| Tickets | Fifteen, numbered 8101–8115, every title
prefixed Aster Bay: — spanning open, waiting, resolved, and
closed states, ticket relationships, and one deliberately unassigned
Quick Ticket for manual-triage review |
| Projects | Three, staffed and linked to tickets, in different lifecycle states |
| Workflows and SLAs | Two workflows with transitions, an approval gate, and actions; three SLA policies on a business calendar with a maintenance-day exception, with instances in met, breached, and paused states |
| Evidence surfaces | A redaction with a pending reveal request, one pending and one approved approval, comments of each visibility, saved views, and completed import runs |
The personas are the accounts you sign in with during the review:
| Persona | What they demonstrate |
|---|---|
| Aster Bay requester, and operations requester | The requester portal and Quick Ticket |
| Aster Bay service agent | The Agent Queue and ticket work |
| Aster Bay support manager | Department administration and lifecycle authority |
| Aster Bay project manager | Project stewardship without lifecycle control |
| Aster Bay compliance approver | Approvals and the redaction reveal decision |
| Aster Bay observer without access | The negative case — no group, no access |
| Casey Vendor (external participant) | Bounded outside access, signing in at External Login |
The agent, support manager, project manager, and compliance approver are workers, so a seeded batch takes four unoccupied worker seats. The seed checks the limit before it writes anything and refuses if the seats are not there. Four seats is more than the Free Edition carries, so a Free installation cannot seed demo data at all. Evaluate under a Trial licence, or on an installation whose licence leaves at least four worker seats free — see Editions.
Credentials
Every persona in the batch shares one generated password, created fresh for that batch. There is no fixed demo password.
The password is shown in the Credentials tab and at the top of the review guide, under Use these credentials throughout the active review batch, together with the sign-in names. It is stored protected at rest, so it remains reviewable — behind step-up — for as long as the batch is active. It is never written to audit history or logs.
Purging the batch destroys the stored credential permanently. If the credential can no longer be decrypted — the message is "Stored demo credentials could not be decrypted. Preserve the configured Data Protection key ring, or purge and seed a fresh demo batch." — the recovery is exactly that: purge and seed a fresh batch. This is one more reason the Data Protection key ring folder is in the continuity set in Requirements.
The review guide
After a successful seed the page switches itself to the Review guide tab — a six-step walkthrough headed Start the Aster Bay walkthrough. Its steps link into the real workspaces: the admin map (departments, workflows, services, role mappings, SLA policies), the requester path, the agent workflow path, the project path, the external and disclosure path, and the evidence path (search, saved views, import operations).
The guide is the evaluator script. Tracked records is the cleanup scope — the page itself tells you the counts are not the walkthrough.
What purge removes
Purge active batch permanently removes the tracked batch — and more than the seeded rows. The purge walks outward from the tracked records and also removes eligible dependent records created during the evaluation by the demo identities: a portal ticket the demo requester submitted while you were testing, its comments, custom-field values, SLA timers, and checkout records go with the batch. That is the point — a finished evaluation leaves nothing behind. Records that do not depend on the demo batch are not touched.
Purge is guarded twice: the arming acknowledgements, plus its own checkbox — "I understand purge permanently removes the active demo batch and tracked demo-scope dependent records." Running a purge with no active batch does nothing and reports zero removals.
Seeding records DemoDataSeeded and purging records
DemoDataPurged in audit history, with counts but never the
generated password. See Audit events.
If it does not work
- Seed or purge is refused with a "Blocked:" message. Read it — it names the missing precondition: complete the arming acknowledgements, purge the active batch before seeding again, confirm the purge checkbox, or wait for the demo-data action already running.
- "No active tenant found. Configure tenant and department baseline before seeding demo data." Finish first-run setup before seeding. See Tenant and organization.
- The Credentials tab says the batch is present but credentials are not available here. Complete step-up. If step-up is current and the message reports the credentials cannot be decrypted, the key ring the batch was seeded under is gone — purge and seed a fresh batch.
- Seeding is refused for worker seats. The message begins "The current product license allows…" and names your limit and the projected worker count. The batch needs four unoccupied worker seats — under the Free Edition's limit this can never succeed. Remove worker authority from accounts you are not using, or evaluate under a Trial licence.