SYNTHETIC DEMO MODE — isolated sample data held in this browser only. It is not connected to the real database and the account/role selectors here are NOT sign-in. For the real, secured app with accounts and shared storage, go to Secure app.
Lyle Pearson Performance
Mercedes-Benz / Sprinter (demo location)Mercedes-Benz + Sprinter Service
Secure appTV Mode
Brand scope: Mercedes-Benz + Sprinter · production counted once for this shop · CSI reported per brand · technician IDs scoped to CDK (MB/Sprinter location)

Members & invitations

Account membership is separate from the employee roster. Each account binds to one existing internal technician identity, one shop, one role and one reviewing manager, with the shop foreman added as a default participant — technicians cannot choose these for themselves.
Demo only — no email is ever sent. Every address here uses the reserved.invalid domain, so delivery is impossible. “Mark sent”, “Resend” and “Mock acceptance” only move state in this browser. There is no authentication backend, no session, no password, no token verification and no access enforcement. No recipients have been supplied and no invitation is authorized.
Shop foreman participation (default): Morrow, Demo (Foreman) participates by default

Invitation lifecycle

draft → pending → accepted / expired / revoked
Email (synthetic)Technician identityStatusExpiresDemo actions
tech101.demo@example.invalid
Alvarez, Demo · technician
T-101accepted2026-09-15
tech102.demo@example.invalid
Benson, Demo · technician
T-102pending2026-09-24
tech103.demo@example.invalid
Carver, Demo · technician
T-103expired2026-09-03
tech104.demo@example.invalid
Delgado, Demo · technician
T-104revoked2026-09-18
tech105.demo@example.invalid
Ellis, Demo · technician
T-105draft2026-09-28

Accounts

Offboarding disables access and sessions while preserving the person's history. Changing an employer email never changes the bound technician identity, so CDK/TCC joins keep working.
AccountRoleTechnician IDReviewerForeman participant (default)Status
Admin, Demo
admin.demo@example.invalid
adminactive
Nolan, Demo (Service Manager)
service.manager.demo@example.invalid
manageractive
Morrow, Demo (Foreman)
foreman.demo@example.invalid
foremanT-900Nolan, Demo (Service Manager)active
Alvarez, Demo
tech101.demo@example.invalid
technicianT-101Nolan, Demo (Service Manager)Morrow, Demo (Foreman)active
Benson, Demo
tech102.demo@example.invalid
technicianT-102Nolan, Demo (Service Manager)Morrow, Demo (Foreman)invited
Carver, Demo
tech103.demo@example.invalid
technicianT-103Nolan, Demo (Service Manager)Morrow, Demo (Foreman)invited
Delgado, Demo
tech104.demo@example.invalid
technicianT-104Nolan, Demo (Service Manager)Morrow, Demo (Foreman)disabled
Ellis, Demo
tech105.demo@example.invalid
technicianT-105Nolan, Demo (Service Manager)Morrow, Demo (Foreman)invited

What a real backend must add

  • Verified email delivery and a hashed, signed, single-use, expiring invite token.
  • Real sessions with login recovery, plus server-side enforcement of role, shop scope and record scope on every read, write, file download and direct URL — not hidden UI.
  • Immutable audit of invitation issue/resend/revoke, role changes and reviewer reassignment.
  • Session revocation on offboarding, and row-level rules so private coaching text is unreachable even for an administrator with user-management permission.