Demo Mode
Demo Mode turns a clean or working SupportDesk install into a guided support-operations sandbox. It creates realistic demo records and then guides users through the app with scenario buttons, a floating drawer, page hints, arrows, popovers, checklists, and next-step instructions.
Buyer Demo Login
When Demo Mode is enabled, the login page shows one buyer-safe demo account with a Use demo account action. This visible account is a Demo Operator, not a full system admin. It can view and operate the guided demo, reports, Operations Center, Demo Mail Center, delivery diagnostics, knowledge review, and security governance views, but it cannot manage roles, create users, edit critical settings, run destructive recovery actions, or administer API/webhook credentials.
Full administrator credentials are intentionally hidden from login hints, DemoFlow personas, proof exports, and buyer-facing documentation.
What Demo Mode Does
- Seeds realistic data: It creates demo users, requesters, organizations, support contracts, context records, tickets, conversations, attachments, video consultations, consultation recordings, case-file evidence, time entries, invoices, disputes, adjustments, reports, schedules, automations, status components, integrations, delivery logs, demo mail evidence, inbound mail records, AI audit runs, security events, updates, saved views, and guided demo steps.
- Shows guided help: When enabled, authenticated admin and portal pages can show a short page explanation, a Demo Guide drawer, scenario tabs, checklist progress, and a walkthrough button.
- Lets users run a scenario: Each scenario has a Run Scenario button. It opens an intro modal that explains the customer story, what the user should do, what records to open, and what checklist items will be marked complete.
- Tracks progress: Checklist steps are completed by route visits, real app events, or manual completion. Current event steps include notes, replies, time entries, video consultation completion, and closed-ticket edit approval requests.
- Falls back safely: If a walkthrough selector is missing on a page, the demo shows a fallback hint instead of breaking the page.
Safe-Upsert Behavior
The main seeder is ScenarioDemoSeeder. It is designed to be re-runnable. It uses stable demo keys such as TKT-2026-1001, INV-DEMO-2026-001, organization slugs, requester emails, scenario keys, schedule names, and rule names.
- It updates existing demo records when the same stable key already exists.
- It does not delete normal user data.
- For known demo tickets and demo invoices, it clears and rebuilds only their child demo records such as replies, notes, attachments, time entries, line items, adjustments, and disputes. This keeps repeated seed runs clean without duplicating child rows.
- Demo automation rules remain inactive by default so they can be reviewed before they affect live ticket behavior.
Activate from Settings
Open Settings > Demo. This section is meant for admins.
| Setting | Meaning | Example |
|---|---|---|
demo_flow_enabled | Main switch for Demo Mode. | Turn on when you want guided demo behavior across authenticated pages. |
demo_hints_enabled | Shows a short layman-friendly page hint. | On the invoices page, it explains that invoices move from draft to review, issue, collection, and settlement. |
demo_auto_modal_enabled | Allows the intro modal to appear automatically. | Useful for first-time demo users. |
demo_drawer_enabled | Shows the floating Demo Guide drawer. | Use this when users should always see the current scenario and checklist. |
demo_flow_version | Progress grouping key. | Change this when you want a new clean walkthrough version without deleting old data. |
Settings Actions
| Action | What it does | When to use it |
|---|---|---|
| Seed / Refresh Demo Data | Runs php artisan db:seed --class=ScenarioDemoSeeder --force. | Use it after installation, after a demo reset, or after demo seed code changes. |
| Reset Demo Progress | Clears only demo progress/state records. | Use it when you want the same user to run the checklists again from the start. |
Commands
Run these from the Laravel project root.
php artisan migrate --force
php artisan db:seed --class=ScenarioDemoSeeder --force
Reset checklist progress without touching seeded business data:
php artisan demo:reset-progress
Scheduled reports are part of the finance demo. To send due scheduled reports manually:
php artisan reports:send-scheduled
In production, do not rely on manual runs. Configure Laravel's scheduler:
* * * * * cd /path/to/SupportDesk && /usr/bin/php artisan schedule:run >> /dev/null 2>&1
The scheduler runs reports:send-scheduled hourly, plus SLA checks and automation runs. If the queue driver is async, also keep a queue worker running:
php artisan queue:work --tries=3 --timeout=120
Active Demo Scenario
The current product demo intentionally focuses on one complete business story instead of showing several competing scenarios. The active scenario is Acme Labs zero-setup support workflow.
Acme Labs zero-setup support workflow
Purpose: Show the whole support operation from a clean starting point: admin setup, customer ticket intake, lead triage, agent investigation, manager approval, customer follow-up, resolution, closure, feedback, and final admin checks.
| Phase | Actor | What to show |
|---|---|---|
| Admin setup | Admin | Review seeded staff, requester, organization, contract, support team, and ticket setup records. |
| Customer ticket | Maya Chen | Create one focused Acme Labs portal ticket with the correct organization, requester, department, category, context, and attachments. |
| Lead triage | Nida Rahman | Open the same ticket, confirm routing/SLA/account data, set Priya ownership if needed, and save the internal triage note. |
| Agent work | Priya Mehta | Add the investigation note, check evidence, log time, and send a customer-visible reply that can go to manager review. |
| Manager review | Ammar Shah | Read and approve the pending customer-visible update before the customer sees it. |
| Customer response | Maya Chen | Open the same ticket, read the approved support update, and reply with updated logs when needed. |
| Resolution | Priya Mehta | Add root-cause notes, final public reply, resolution summary, and final time. |
| Closure | Ammar Shah | Check closure readiness and close the same ticket after the required approvals and evidence are clean. |
| Final review | Maya and Admin | Submit feedback or verify reporting, delivery, permissions, organization, contract, production readiness, AI trust, security governance, and operations state. |
Current Demo Structure
| Layer | Source of truth | Current behavior |
|---|---|---|
| Business data | InterlinkedDemoSeeder | Creates users, accounts, contracts, context records, tickets, conversations, attachments, approved/completed video consultations, recordings, invoices, status operations, integrations, and saved views. |
| Guided scenario | DemoFlowSeeder | Creates the active Acme Labs scenario cards, route/event/manual checklist steps, tour selectors, and the support-ops-v3-finalized-governance flow version. Legacy scenario definitions are kept inactive for now. |
| Page hints | DemoPageGuideRegistry | Explains ticket queue, ticket workspace, video room, Case Files, reports, settings, operations, and portal pages from the current UI. |
| UI shell | resources/views/demo-flow | Renders the drawer, scenario cards, intro modal, page hint, and tour JSON using shared Blade components. |
| Component rule | usage/, resources/views/components, app/View/Components | Demo-facing pages should use the shared table, tabs, page header, button, form, and metadata components instead of one-off markup. |
Demo Operating Tools
- Demo Control Center: shows Demo Mode status, active scenario, persona accounts, seed health, progress, restart action, and persona handoff buttons. Handoffs use DemoFlow routes only, not general impersonation.
- Demo Proof Export: provides buyer-facing JSON/PDF evidence for health status, release checklist, deploy smoke, AI Trust, mail diagnostics, knowledge governance, security governance, Operations Risk cards, and demo completion/rating. Secrets and hidden admin details are excluded.
- Completion modal: appears once after the active admin scenario completes, summarizes what was proven, records optional 1-5 demo feedback, and offers Replay Demo or Open Operations Risk actions.
- Email evidence card: links the final scenario to Demo Mail Center, Delivery Diagnostics, inbound mail detail, mailbox test webhook, and capped proof email.
Run Scenario Button
Each scenario card has a Run Scenario button in the Demo Guide. Clicking it opens a scenario intro modal before the walkthrough starts.
- What this scenario is: A plain-language explanation of the business story.
- Who you are acting as: For example, support agent, account owner, finance lead, or operations admin.
- Records to open: Example ticket numbers, invoice numbers, organizations, contracts, or status records.
- Checklist: Tasks that should become checked as the user moves through pages or performs actions.
- Start Walkthrough: Highlights the current page element with a spotlight, arrow, and popover when a selector is available.
How Checklist Progress Works
| Completion type | How it gets checked | Example |
|---|---|---|
route_visit | User opens the expected route. | Open Reports, Invoices, Organizations, Status Center, or a ticket detail page. |
event | The app records a real demo event. | Create a ticket note, send a reply, log time, create an adjustment, or visit a portal ticket. |
manual | User clicks Done or Skip in the Demo Guide. | Useful when the training step is reading a page or discussing a concept. |
Page-Level Guidance
Demo Mode uses a central route-keyed guide registry. Each guide can define:
- What the page is for in simple language.
- The checklist items the user should complete on that page.
- The primary next action.
- Spotlight selectors for arrows and popovers.
- Fallback copy if the selector is missing.
The registry covers dashboard, ticket queue, ticket detail/workbench, video room, Case Files, organizations, contracts, context hub, playbooks, automation, reports, report schedules, invoices, status center, settings, users, roles/permissions, integrations, operations, identity, and requester portal ticket pages.
Portal Demo Behavior
Authenticated requester portal pages receive only valid requester-facing guide data. Admin-only scenario steps are not shown to portal requesters. This matters because portal users should learn ticket submission, ticket visibility, shared organization tickets, public replies, attachments, and status information without seeing internal finance or automation controls.
Seeded Record Reference
| Area | Seeded examples | Why it is included |
|---|---|---|
| Internal users | Admin, Nida Rahman, Bilal Khan, Priya Mehta, Ammar Shah. | Shows admin, agent, billing, technical, lead, and approver responsibilities. |
| Requesters | Maya Chen, Jordan Price, Samir Hussain, Ayla Noor. | Shows portal access and shared account visibility. |
| Organizations | Acme Labs, Northwind Retail, Skyline Health. | Shows different account profiles and customer situations. |
| Contracts | Premium support and managed operations contracts. | Shows coverage, channels, priorities, limits, SLA overrides, and entitlements. |
| Tickets | Billing export, gateway incident, employee access, split follow-up, duplicate billing. | Shows real support queue patterns instead of fake one-line tickets. |
| Conversations | Customer replies, internal notes, duplicate review notes, incident updates. | Shows how communication differs by audience. |
| Evidence | Public files, internal files, redaction-needed finance note, telemetry, audit files, and a demo consultation recording. | Shows attachment visibility, Case Files metadata, recording governance, and compliance handling. |
| Video consultations | One approved active consultation and one completed consultation with a recording. | Shows approval, same-app room links, completion handoff to Conversation, recording retention, and Case Files indexing. |
| Finalized ticket lock | Resolved TKT-2026-1003 plus the closed-edit approval form. | Shows the read-only state and the admin approval path required before any edit action is allowed. |
| Time and billing | Billable, non-billable, and overage time across several dates. | Shows how work becomes invoice line-item traceability. |
| Invoices | Seven workflow states with line items, sources, credits, disputes, and collection notes. | Shows finance from draft to settlement. |
| Status operations | Eight status components and issue updates across active, monitoring, resolved, and closed groups. | Shows public incident communication and internal operations visibility. |
| Integrations | API clients, webhooks, webhook deliveries, email/database/delivery logs. | Shows success, queued, recorded, and failed delivery states. |
| Saved views | At Risk Incidents, Billing Queue, Finance Follow-up, Gateway Incident Work, Portal Visibility Review. | Shows personal queue shortcuts for different roles. |
Recommended Demo Path
- Seed demo data from Settings > Demo or run
php artisan db:seed --class=ScenarioDemoSeeder --force. - Open the Demo Guide drawer.
- Click Run Scenario on Acme Labs zero-setup support workflow.
- Follow the cards in order: Admin, Maya, Nida, Priya, Ammar, Maya, Priya, Ammar, Maya, Admin.
- Use the sign-in handoff button whenever the next step belongs to another user.
- Keep the whole story on the same Acme Labs ticket, contract, organization, and support team.
- Reset demo progress when another person needs the same guided path.
Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
| Demo drawer does not show. | demo_flow_enabled or demo_drawer_enabled is off, or the user is not authenticated. | Open Settings > Demo and enable both switches. Log in as an admin or portal requester. |
| Page hint does not show. | demo_hints_enabled is off or the route has no guide entry yet. | Enable hints. If the page is custom, add it to the guide registry. |
| Run Scenario opens but arrow does not point to an element. | The page markup changed and the selector no longer exists. | The fallback hint should appear. Update the route guide selector for the new component. |
| Checklist does not reset. | Progress is saved by user, guard, and flow version. | Use Reset Demo Progress or change demo_flow_version. |
| Video completion step does not complete. | No approved active consultation is present, or the user skipped the Complete confirmation. | Refresh demo data, open TKT-2026-1004, use the Video tab, and confirm completion. The record should move to Conversation history. |
| Closed ticket still allows editing. | The user has an active closed-edit approval window, or the status is not treated as finalized. | Open the closed-edit panel and check whether an approval is active. Resolved, closed, and completed demo tickets should be read-only without that approval. |
| Scheduled report demo does not send email. | No due schedule, mail not configured, queue worker missing, or scheduler not running. | Check reports:send-scheduled, mail settings, queue:work, and server cron. |
| Seeded data duplicates child rows. | A custom demo extension created child rows outside the stable demo rebuild area. | Use stable keys and clear only known demo children before recreating them. |
Screenshots To Add
These placeholders are intentionally kept in the docs so release screenshots can be dropped in later without changing the written guide for Demo Mode.