Skip to content

Support Portal Demo

Ordered runbook for showcasing Floh as an IT support portal: five catalog cards (self-service + approval + ticketed fallback), My Tickets, and the admin Tickets hub.

This pack is seeded via an opt-in CLI (LSA-9767). It does not run during migrations, so production catalogs stay clean.

For ticketing mechanics alone, see Service Ticketing Demo.

Start the stack

# Terminal A — infra, migrations, API :7070, admin web :7072
pnpm dev:all https

# Terminal B — portal BFF :7071 + portal SPA :7073
pnpm dev:portal:https
Port App
7070 API
7071 Portal BFF
7072 Admin web
7073 Portal SPA

Seed the demo pack

Requires NODE_ENV=development or test (the CLI fail-closes otherwise).

pnpm seed:support-portal

Creates (insert-if-absent by name — safe to re-run):

  • IT Support ticket queue + IT Support Standard SLA
  • IT Approvers group (demo actor is a member)
  • Five catalog-published workflows:
Card Behavior
Reset my password Self-service run (simulated transform — no connector / no ticket)
Request access Approval by IT Approvers (no ticket)
Hardware support Creates ticket #N in IT Support
Software request Creates ticket #N in IT Support
General IT support Creates ticket #N in IT Support (fallback)

One-time: add your agent to IT Approvers

Access-request approvals target the IT Approvers group. Add your agent (or admin) user to that group in Admin → Groups so you can decide the pending approval during the demo.

Demo script

1. Browse the catalog

Where: Portal https://localhost:7073/requests/catalog

  1. Sign in as a requester
  2. Confirm five support cards with distinct icons/tags
  3. Note: topic selection = which card you open (Floh’s catalog model)

1b. Knowledge auto-suggest (LSA-9070)

Requires at least one published article in Admin → Tickets → Knowledge (markdown editor: Markdown textarea + Preview).

  1. Open a ticketed catalog card (Hardware / Software / General IT)
  2. Type 3+ characters in the effective title field (ticketTitle, or the workflow’s create_ticket.titleVariable)
  3. Confirm Related articles appears under the form
  4. Click a title — a right-side p-drawer opens the sanitized article. The catalog dialog stays put (no route change)

What to say: Suggest watches the create-ticket title variable, then description. Unpublished drafts never appear. Bodies are markdown only — {{submitter.*}} stays literal.

2. Password reset (self-service, no ticket)

  1. Open Reset my password → Submit
  2. Expect: “Your request was submitted.” (no ticket #N)
  3. Optional: Admin → Runs — show completed run + resetConfirmation variable

What to say: Self-service cards can omit create_ticket. This demo simulates the reset; for production, follow Google Workspace Password Reset.

3. Access request (approval)

  1. Open Request access — fill access target + justification → Submit
  2. Sign in as an IT Approvers member → Tasks → Approvals tab → Review
  3. Confirm the Review dialog shows workflow, requestor, submitted values (justification / access target), then choose a decision:
  4. Approve — completes the approval path and lets the run continue
  5. Reject (Resubmit) — returns the request for another submission (run does not complete as approved)
  6. Final Reject — terminal rejection; the workflow does not proceed
  7. Confirm the run outcome matches the decision

What to say: One catalog card, specialized fulfillment path (approval), still no ticket unless you add create_ticket. Approvers no longer need to open the full run to see the justification (LSA-9768).

4. Hardware / Software / General IT (tickets)

  1. Submit each ticketed card with a title + description
  2. Confirm toast: submitted as ticket #N
  3. Portal My Tickets → open #N
  4. Admin https://localhost:7072/tickets → assign, comment, change status

What to say: Ticket creation is opt-in via the create_ticket step. Queue/SLA come from the workflow’s Catalog Publishing binding (seeded to IT Support).

5. Fallback story

  1. Ask “what if none of these fit?” → open General IT support
  2. Submit → ticket with request type other

Optional: real password reset

Replace the simulated transform on Reset my password with a Google Workspace setPassword connector per Google Workspace Password Reset. Keep the card published; re-running the seed will not overwrite an existing card with that name.

Optional advanced: triage via sub-workflow

This seed intentionally uses one catalog card per topic (Floh’s primary portal model). After PR #1038 (LSA-9766), authors can also build a single intake workflow that delegates to specialized children with the Sub-Workflow palette step — see Sub-workflows. Nested runs are not yet surfaced in the portal timeline; prefer catalog cards for demos unless the story is explicitly about composition.

Re-seeding

pnpm seed:support-portal is safe to re-run. It only creates rows whose canonical names are missing (or soft-deleted for workflows). Existing demo cards, queues, and groups are left alone — including hand-edits. To recreate a card after deleting it in Admin, re-run the seed.