02 — User Personas (Scheduler Module)
- Persona 1 — The Platform Operator ("Nadia")
- Persona 2 — The School IT Admin ("Mr. Okonkwo")
- Persona 3 — The On-Call Engineer ("Priya")
- Persona 4 — The Domain Module Owner ("Dev")
- Non-persona: End Users (students / parents / teachers)
- Shared profile notes
The scheduler is infrastructure: its users are the operators who keep recurring work running. Personas are derived from the access model (
scheduler.controller.ts:16-24—JwtAuthGuard+Permissions) and from how the module is consumed (scheduler.service.ts,jobs/*.job.ts,infrastructure/workers/*). No end-user persona exists by design — the PRD native-app exclusion applies (see 01 §5).
Persona 1 — The Platform Operator ("Nadia")
Role: Platform superadmin at StudyLyon HQ. Owns the multi-tenant deployment; the only actor with cross-tenant visibility.
| Attribute | Detail |
|---|---|
| Goal | All recurring work fires on time, every tenant |
| Pain | Silent failures: a digest that never sends is noticed by schools, not by logs |
| Tools today | GET /scheduler list + Redis/BullMQ CLI inspection; no run history (gap → console (proposed)) |
| Authority | scheduler.read / scheduler.create / scheduler.delete permissions (scheduler.controller.ts:24,31,38) |
| Behaviors | Checks the job list at deploy time; watches for missed runs after deploys or Redis restarts |
| Wants | Last-run/failed timestamps, one-click manual trigger, DLQ visibility, alerting on missed runs |
| Fears | BullMQ repeatable jobs silently deregistered on a redeploy; backlog storms after a long outage |
Persona 2 — The School IT Admin ("Mr. Okonkwo")
Role: IT administrator of one school tenant. Does not touch the platform scheduler itself; consumes its outputs.
| Attribute | Detail |
|---|---|
| Goal | Parents/teachers get the daily digest, attendance reports, and fee reminders they expect |
| Pain | Reports arrive late or not at all after school-hours (07:00 UTC is early for some timezones) |
| Surface | None directly — receives emails (emails queue), report outputs (report-generate) |
| Behaviors | Files tickets like "today's attendance report never arrived" |
| Wants | A per-tenant "scheduled reports" view with delivery status (proposed) |
| Fears | Missed report = parents complaining; fee reminder missed = cashflow friction |
Persona 3 — The On-Call Engineer ("Priya")
Role: Backend engineer on rotation. Primary responder for queue/DLQ incidents.
| Attribute | Detail |
|---|---|
| Goal | Diagnose a missed or failed job in minutes |
| Pain | Repeatable triggers are fire-and-forget; failure detail lives in BullMQ + DLQ internals (dlq.setup.ts:5-27) |
| Tools today | BullMQ dashboard, Redis CLI, logs |
| Behaviors | Greps job names (check-overdue, send-daily-digest, …); checks attemptsMade vs attempts |
| Wants | Job logs screen, DLQ viewer with retry, idempotency check info |
| Fears | Replaying a job that was already half-processed (double sends) |
Persona 4 — The Domain Module Owner ("Dev")
Role: Developer of fees/attendance/admissions modules that register jobs and consume the queues.
| Attribute | Detail |
|---|---|
| Goal | Their module's async work is triggered reliably without re-inventing cron |
| Surface | Register via SchedulerService injection or repeatable queue.add; consume via workers |
| Behaviors | Adds eventType to event-queue-map.ts for event-driven paths, or a repeatable job for scheduled paths |
| Wants | A documented contract: payload envelope (JobData), tenant restoration in workers, DLQ on failure |
Non-persona: End Users (students / parents / teachers)
No scheduler surface. They interact only with delivered artifacts
(digests, reminders, reports). Any direct scheduling capability in their
apps is (forward-looking).
Shared profile notes
All authenticated personas share: bearer JWT (scheduler.controller.ts:17),
RBAC via Permissions decorator, and response envelopes per 00-shared/07.
Analytics for console screens is (proposed) — no events exist today
(00-shared/10 §8).