Wellness Passport — staff manual

How to run a Digital Wellness Challenge from the admin app: building and publishing a challenge, running events, correcting records, sending reminders, reviewing responses and pulling reports.

Written for CSU Bakersfield Student Health Services staff and event attendants. For the same material told as one semester end to end, see the product walkthrough.

How the app is organised

One web app, two faces. Students get a phone-first passport they can install to their home screen. Staff get an admin app with five destinations on a navigation rail. Both are reached from the same sign-in page.

Rail destination	What it is for
Builder	Author, publish, preview and retire challenges; review responses; correct check-ins.
Reports	Live dashboard, CSV exports, prize lists and the all-reports ZIP.
Verify	Scan a student's personal QR and confirm a task in person.
Notify	Send, edit or skip proposed reminders; compose broadcasts.
Themes	Create and edit the semester's look.

The Live event screen (event QR, backup code, live count) is opened from a week's row in the Builder rather than from the rail, because it is always about one specific week.

The admin app works on a phone as well as a desktop. On a desktop (1024px and wider) the screens use two columns and the Reports stat tiles appear; on a phone everything stacks in one column and the rail sits across the top. Every control is a full-size touch target.

Getting started

If you are new to this, do not read the rest of this manual first. Open Getting started in the admin rail. It is a short checklist per job — building the challenge, running a table, reading what came back, and checking students in — and every step ticks itself once you have actually done the thing. There is nothing on that page to mark off by hand, which is the point: it reports what you have done, not what you have read.

Each step links back to the section here that explains it, so the page is also the fastest way into this manual. Two of the lists are worth printing rather than reading on screen. Print this list on any of them opens a one-page version with no app around it, and needs no sign-in at all — that is the copy to hand to whoever is running a table, since an attendant holds a display link and has no account. The page also records who at your campus has finished which list and when, which is the answer to "has everyone been trained" without anybody having to remember.

While you still have steps outstanding, signing in takes you to Getting started first. Once you have finished, or once you press Do not open this first on this device, you land on the Builder as usual. That preference is per person and per device, so dismissing it on your own laptop does not take it away from a colleague on the shared machine.

Signing in and roles

Everyone signs in with campus SSO. There are no passwords or accounts inside the app.

Who is an admin

ITS maintains a mapping from a campus group (for example shs-wellness-admins) to the app's admin role. Anyone the identity provider says is in that group holds the admin role after signing in and sees the admin app. Everyone else holds the student role and sees the passport.

Adding or removing a staff member is a group-membership change made by ITS; it takes effect at that person's next sign-in and needs no change to the app.

An event attendant does not need an account at all. To staff an event table, an admin creates a display link from the Live event screen and opens it on the tablet: it shows that week's code and check-in count and nothing else, and it ends when the admin revokes it or the week's window closes. See Attendant.

Verify is different, and stays admin-only: recording who verified a student needs a signed-in person to record.

The app refuses. A student who navigates to an admin address is returned to their passport. A direct call to any admin function from a student session is rejected. An affiliation value that merely contains the word "administration" grants nothing unless ITS has mapped it.

Signing out and sessions

Sign out is at the bottom of the rail. Sessions use secure, HTTP-only cookies; when a session expires you are returned to sign-in.

A session lasts one hour. Plan for it at a long event: an admin who signs in on a tablet at 10:00 to show the event QR is signed out around 11:00, and the code stops refreshing until somebody signs in again. For a staffed table, use a display link instead — it keeps showing the rotating code for the whole shift without a session on the device, and an admin can end it at any time. Do not photograph the code and pass the picture around, because a code that stops rotating stamps people in who were never there.

Sign-ins, sign-outs, expired sessions, refused admin requests, rate-limit trips, display links being issued, revoked or refused, and weeks being archived or restored are recorded in a security-event ledger that an admin can export for their campus (see Privacy and audit).

Challenges, weeks and statuses

A few terms appear everywhere in the admin app. This is what they mean.

Term	Meaning
Challenge	One semester's program: name, semester, start and end dates, a theme, an ordered list of weekly tasks, and optional assessment items. Has a status of draft, published or archived.
Live challenge	The one published challenge students at your campus currently see. Exactly one is live at a time. The Builder badges it Live; any other published challenge is Not live.
Week / task	One row in the challenge: title, caption, activity type, location, a date window (optionally with start and end times), a prize, and a Required flag. "Week" and "task" are the same thing; the student sees it as a week tile.
Required	A week that counts toward grand-prize eligibility. A student is prize-eligible once every required week is complete. Optional weeks still count for the weekly drawing.
Check-in	The record that a student completed a week. Carries the student, the week, a timestamp and a method (below).
Assessment item	A multiple-choice question (auto-scored) or a reflection prompt (read by staff, never scored), attached to a week and tagged to a learning outcome.
Theme	The look of the student app for a challenge: palette, app title, tagline, logo and hero art. The built-in default is CSUB.

Week status, as a student sees it

Status is decided by each week's own date window and the campus clock, never by whether earlier weeks were completed.

Status	When	Can the student check in?
locked	The week's window has not opened yet.	A scan of that week's event QR is still accepted if staff run the event early.
available	Today is inside the window (and inside the time window, if one is set).	Yes, by scanning the event QR.
complete	A check-in exists for the week.	A second scan shows Already completed.
missed	The window closed with no check-in. Shown as Missed — still open.	Yes, at a later event or make-up session. It still counts toward the prize.

A week with no window at all is always available. A week with dates but no times is judged by date; a week with times is judged to the minute in the campus time zone, so a 10:00–14:00 event reads locked at 09:30, available at 11:00 and missed at 14:30 on the same day.

Check-in methods

Method	How it is recorded	Shown in reports as
`event_qr`	The student scanned the live event QR, or typed its backup code, on their own phone.	Auto (event QR) / "Automatic"
`staff`	Staff scanned the student's personal QR on the Verify screen and confirmed the task. Records the verifying staff member.	Manual / staff
`manual`	An admin used Mark complete in the check-in panel with a reason. Records the admin as verifier and writes an audit row.	Manual / staff, with a data-quality note separating audited overrides from any legacy self-reported rows

There is no self-service completion: the passport offers no button that completes a week without a scan, and a request to complete a week without a valid event credential is refused.

Builder

Route: /admin

The Builder lists every challenge at your campus and is where a challenge is authored, previewed, published, reviewed and retired. Challenges are written by staff; there is no document import and nothing is drafted by a model.

Create a challenge

Press New challenge.
Fill in the Challenge form: Challenge name (e.g. Fall 2026 Wellness), Semester (e.g. Fall 2026), Start date, End date, and Theme (pick from the Themes library; Default is the CSUB theme). The theme note reminds you that switching themes needs no code change.
Press Create challenge. The challenge is saved as a draft and opens for editing. Edit details reopens this form later; Save changes saves it.

The app refuses an end date earlier than the start date. The error names the date that is wrong, and the stored challenge keeps its previous dates.

Weekly tasks

Press Add task in the Weekly tasks list.
Fill in the Task form:
- Title: shown as the week tile, e.g. Week 1 – Vision Check.
- Caption: the short description under the title.
- Activity type (e.g. health_screening) and Location (e.g. SHS Lobby). Both appear in the per-event export; location appears as Where on the student's week sheet.
- Window start / Window end: the dates the week is available. A single day is fine; leaving both empty makes the week always available.
- Start time (optional) / End time (optional): narrows a day to an event time. The student sees Wed Sep 23, 10:00 AM – 2:00 PM.
- Prize (e.g. Raffle entry).
- Required task (counts toward prize eligibility).
Press Save changes. Edit task on a row reopens it.
Reorder with the Move up / Move down buttons on each row. They are disabled at the ends of the list, announce the move, and work by keyboard and on a phone. A reorder the server refuses is rolled back on screen and reported.

The app refuses a window end before its window start, or a window start after its end (the error names the offending date), and a start or end time without the matching date.

Removing a week

A week that students have touched cannot be deleted — archive it instead. The app refuses to delete any week holding check-ins, responses or views, and any week at all on a published or archived challenge; the refusal names what blocks it (for example 40 student check-ins) and offers Archive week. There is no override.

Archive week hides the week from students and stops it counting toward completion and prize eligibility, while keeping every check-in and response exactly as they are. Archived weeks are hidden from the Weekly tasks list until Show archived weeks is ticked; Restore week brings one back, stamps and all, and a Required week counts toward prizes again the moment it returns.

The other weeks keep their own numbers. Archiving week 3 leaves weeks 1, 2, 4 — week 4 is not renumbered, because that is what students, the exports you have already downloaded, and your records all call it.

Delete appears only on a week the app would actually let you delete: a week on an unpublished draft that no student has touched. It removes the week straight away, with an Undo offered for 30 seconds — or until you reorder the weeks, whichever comes first. There is no are you sure?, deliberately: the actions worth stopping are refused outright, and the ones that are not are simply undoable.

Archiving and restoring a week are both recorded in the security-event ledger (see Privacy and audit).

On Reports. An archived week leaves participation and the prize files, because it asks nothing of anyone any more. It stays in the attendance and per-event exports, marked archived, because the check-ins really did happen — archiving is not a way to un-happen a week.

Knowledge checks and reflections

Assessment items hang off a week and are offered to the student after they check in (Take the knowledge check).

Press Add item under Assessment items.
Choose the Item type:
- Multiple choice (MCQ): Prompt, Options (min 2), Answer key (must exactly match one option), and a Learning outcome tag (e.g. sleep-hygiene). Scored instantly when the student answers; the score is stored against the tag.
- Reflection: Prompt and an optional What to look for note. This note is shown to reviewers beside the responses to keep two staff reviewers consistent; it is never shown to students and nothing is ever scored.
Save. Items can be edited later; a reflection's What to look for note can be added after the fact.

The app refuses an MCQ with fewer than two non-empty options, or an answer key that does not match one of the options.

Preview as student

On any challenge at your campus (draft, published or not live) press Preview as student.
The passport renders inside a phone frame exactly as a student would see it, with the challenge's own theme, name and week tiles. The banner reads Previewing as a student — nothing here is saved, and check-in is disabled. Week statuses reflect the dates, so a challenge already under way shows available and missed weeks, not every week locked.
Press Back to builder (present while loading, on error and when loaded) to return.

Previewing writes nothing: no enrollment, check-in or assessment response is created, and no scan control is offered inside the frame.

Rehearse the check-in

Preview shows you what a student sees. Rehearsal lets you be one, so you can watch a stamp actually land before you do it in front of a queue of students. It is the way to learn the check-in without a test student account and without anything counting.

Press Rehearse in the admin rail, at the bottom next to Sign out. The app is now the student app on that device, with a banner reading Rehearsal: nothing here counts.
Use it exactly as a student would: enroll, open the passport, open My QR, scan the event QR off the projected screen or a display tablet, or type the backup code.
The week flips to complete and the post-check-in tip appears, the same as it will for a real student. Take the quiz and write a reflection if you want to see those too.
Press Exit rehearsal in the banner to go back to the admin app.

What is real, and what is not. The rows are written for real, which is the point: that is why the week persists, the tip appears, and Live reacts. What changes is that nothing about your rehearsal is ever counted as a student. It appears in no report, no CSV, no ZIP bundle, no prize list and no review panel; the Notify queue never proposes or sends a reminder to it; and your rehearsal passport shows its prize indicator as Rehearsal, never as eligible, however many weeks you complete.

On Live event the count you are watching stays the real one. The Checked in — live card keeps showing real students only, and a rehearsal scan is added beside that number rather than to it, as (+1 rehearsal), so rehearsing never inflates the figure you are reading off the screen at an event.

One rehearsal student per person. Your first rehearsal creates it and every later one reuses it, so your rehearsal passport is where you left it. Press Reset rehearsal in the banner to clear it back to a fresh passport: the check-ins, quiz answers and reflections go, and the reset is recorded in the audit ledger.

Two devices are two sessions. Rehearsing on your phone does not touch the desktop you left on Live. That is the intended way to do it: the desktop shows the event screen, the phone stands in for the student.

While you are rehearsing, the admin screens are closed to you. The Builder, Reports, Verify and Notify all refuse a rehearsing session, because for as long as the banner is showing, that device is a student. Press Exit rehearsal first. Your other devices are unaffected.

Rehearsing Verify. Verify works against a rehearsal student like any other, so two staff can rehearse the higher-assurance flow together: one puts a phone in rehearsal mode and opens My QR, the other scans it on Verify and confirms a week. The check-in is recorded with method staff, and it is excluded from the reports in the same way.

Publish, Live and Not live

Open the draft and press Publish.
If no challenge is live at your campus, it publishes immediately and is badged Live.
If a running challenge would be displaced, a dialog titled Publishing will replace the running challenge names that challenge, its enrolled-student count and its recorded check-in count. Press Publish anyway to proceed or Cancel. A refused publish changes nothing: every student's progress and every event QR stay valid.
Publishing a challenge that would not win the live slot needs no confirmation; it is badged Not live, and editing it shows a note that the change will not reach students yet.

The list always shows which one challenge students are seeing. A student at your campus resolves exactly one challenge, and it is the one badged Live.

Review panels

On a published challenge's detail screen, below the weeks, two panels sit side by side on a desktop (stacked on a phone).

Reflection review. Caption: Read what students wrote and mark each one reviewed. Collapsed to a count of items, responses and how many are still unreviewed. Show responses on an item loads and lists only the unreviewed responses, with the item's What to look for note above them. Long responses are clamped with Show full response. Mark reviewed drops a response from the list and raises the reviewed count. Show reviewed (N) brings reviewed ones back; Mark reviewed again re-records your review. There is no score control anywhere in this panel.

MCQ score override. Collapsed to a count of items, responses and how many were hand-scored. Expanding an item lists each response with its score and how it was scored (auto or human). If a question was faulty, set Score (0–1) on a response and Save. The override is logged with your staff id and a timestamp, and is reflected in the Learning outcomes report.

Check-ins and manual overrides

Every week has a check-in panel, opened from its row in the Builder or from the Live event screen. It has two tabs.

Check-ins tab

Lists every check-in for the week, each row naming the student by SSO subject, with the method and time.
Mark complete: enter the Student SSO subject and a Reason (Why is this being marked by hand?). Records a check-in with method manual, you as verifier, and an audit row.
Remove on a row: enter a reason (Why is this change being made?). The check-in is removed; the prior state is kept for audit.

Audit trail tab

Every add, change and removal, with who did it, when, the reason, the student it was about, and a Prior state snapshot. Rows keep naming their student even if that student's record is later deleted.
Show history for narrows the ledger to one student (All students restores it).

Close the panel with the ✕ in its header (focus lands there when it opens), with Escape, or with Done at the bottom. Escape first cancels an open reason prompt or manual form, then a second Escape closes the panel. Tapping the dimmed area outside does not close it, so a half-typed reason cannot be lost to a stray tap.

The app refuses marking complete a student who already has a check-in for that week: That student is already checked in for this task — use Remove, then re-add.

Duplicate, Archive, Delete

Duplicate asks for a New challenge name and Semester, then creates an independent draft with the same weeks, quiz items and theme. Editing the copy never touches the original. The usual way to start a new semester.

Archive (Archive this challenge? You can restore it later.) is for any challenge that ran. It keeps every task, response, check-in and audit row, leaves the default list (Show archived reveals it), is never shown as live, mutes its reminders, and stays reportable by selecting it on Reports. Restore republishes it, subject to the same displacement guard as Publish (Restoring will replace the running challenge / Restore anyway).

Delete is only for untouched drafts. Delete (Delete this draft?) works only on a draft that was never published and has no student data; its name and semester become available again. A published or archived challenge, or a draft that once had check-ins, cannot be deleted; the refusal names what blocks it and offers Archive instead. Nothing is ever removed from the audit ledger.

Live event

Route: /admin/live/…

The screen you run an event from. Opened with the Live button on a week's row in the Builder (the rail's Builder destination stays highlighted while you are here).

On screen

Event QR — students scan to check in. Large enough to project or hold up on a tablet. It encodes a signed token bound to this week of this challenge. Do not print it: the code rotates, so a printed one stops working within a minute.
Backup code for manual entry, e.g. WK4-7291, printed beside the QR. Read it out to a student whose camera will not work; they type it on the scan sheet.
Code refreshes automatically: the token rotates about once a minute on its own, and the screen re-fetches twice as often so what is on screen is always current. Rotate code forces a fresh one immediately.
Checked in — live: the count for this week, updating as scans land, with a Recent check-ins list. No check-ins yet — waiting for the first scan until the first one.
Get display link creates a link that shows this week's code on a device with no sign-in — see Attendant. Display links lists the ones that are live, with Revoke to end one.
The week's check-in panel opens from here for on-the-spot corrections; closing it refreshes the count.

How the codes behave

A scan or code is accepted only for the week it was minted for, in the live challenge, for an enrolled student. The confirmation names that week.
A token older than its rotation window is rejected and the student is told to rescan the current code. The typed backup code is a little more forgiving: the current window and the one before it are accepted, anything older is refused as stale.
The backup code is case-insensitive and ignores the hyphen and surrounding spaces.
Codes from a past semester, from a task that was deleted and replaced, or forged codes are refused (This code is no longer valid, ask the attendant) and the attempt is logged. Repeated wrong guesses are rate-limited.
A check-in after the week's time window has closed is still recorded (that is how catch-up works) and still counts toward prize eligibility.

Tip. Because the QR rotates, a screenshot shared in a group chat stops working within a minute. Projecting the Live event screen — or opening a display link on the table's own tablet — rather than printing the QR in advance, keeps off-site check-ins out of your attendance numbers.

Attendant

Route: a display link, e.g. https://…/display#…

For staff running an event table who are not administrators. There is nothing to sign into and no account to create.

Before the event. An admin should rehearse the check-in once before a tablet goes out to a table, so that somebody on the team has seen the student side work end to end. See Rehearse the check-in.

Getting one. An admin opens Live event for the week, presses Get display link, and either copies the link or scans the QR in the dialog with the tablet. The link is shown once; if it is lost, make another.

On the tablet. The screen shows the week, the code students scan, the backup code to read out, and a live count of check-ins. Keep the screen awake and on Wi-Fi — the code refreshes on its own about once a minute, and a screen that cannot reach the network will say so and stop refreshing.

What it will not do. It shows no student names and no check-in list, and it opens nothing else in the app. Someone holding the link cannot reach reports, reflections, Verify, or any other week.

When it ends. A display link stops working when an admin revokes it, when the week's window closes, or after 14 hours at the latest — whichever comes first. The screen then reads This display link has ended, ask the attendant; ask an admin for a new one. Deleting or archiving the challenge ends its links too.

Verify

Route: /admin/verify

The higher-assurance way to credit a student: you scan their QR, see whom you scanned, then confirm one task. Use it when you want a named check against a person in front of you rather than a scan of a projected code.

Ask the student to open My QR on their passport (the icon in the top bar, or the rail item on a desktop). Under their QR is a short code like WP-7F3A-92; it is tied to their current session, contains no ID number and no health information, and changes on its own as the QR rotates.
1 · Scan their QR: press Scan passport QR and point your camera at the student's screen. It is the same scanner the student app uses.
2 · Confirm the task: the screen lists the live challenge's tasks. Press Confirm on the right one (or Cancel).
The check-in is recorded with method staff and you as the verifier.

The app refuses a task the student already completed: Already completed / This student already has a check-in for…, and no second check-in is recorded. With no live challenge there is nothing to confirm (No tasks in the active challenge).

Notify

Route: /admin/notifications

Reminders reach students as a banner inside their passport. Nothing is sent by push notification, email or text, and nothing reaches a student until a staff member sends it.

The queue

About every 15 minutes the app proposes reminders from the live challenge's calendar: a new-week reminder the day before a week opens, and an expiring reminder as the challenge nears its end date. Each is proposed once. Draft challenges propose nothing.

Proposed reminders sit under Awaiting your decision (Nothing reaches a student until you send, edit, or skip it.). Each shows its title, body, when it relates to, and the audience: Send to 214 enrolled students?

Send: publishes immediately to the in-app feed of every student enrolled in that challenge. Its status becomes scheduled; that is the final state, there is no later delivery step.
Edit: change the title and body, then Save and send. The edited copy is what students see.
Skip: never sent. Skipped reminders never appear on any student's screen.

Compose a broadcast

Press New broadcast.
Choose the challenge, write a title and body.
Choose the audience: Everyone enrolled, or Only students with an incomplete current week (students who have already checked in for the current week are excluded).
Choose Send now (Send broadcast) or Schedule for a date and time (Schedule broadcast).

Rules that apply to every reminder

Every send, edit and skip is recorded with the deciding admin and the time.
A challenge with notifications disabled, or an archived challenge, sends nothing even if a reminder for it is approved.
A student sees only reminders for the challenge they are enrolled in. Dismissing a banner sticks across reloads.
A reminder stays in a student's feed for 14 days, then retires on its own.
The queue shows audience size (enrollment). There is no device count because there is no device channel.

Reports

Route: /admin/reports

The reporting dashboard answers "how is the semester going?" and produces the files for the prize drawings. Every figure is for the challenge selected at the top.

Choosing the challenge

The Active challenge selector defaults to the live challenge. Any published or archived challenge at your campus can be selected; every card and export then describes that challenge, and export filenames carry the campus, challenge and date.

Stat tiles (desktop only)

Tile	What it counts
Enrolled	Students who joined the challenge.
Prize-eligible	Students who completed every required week. Equals the row count of the grand-prize export. Shown as a suppressed placeholder, never a fabricated zero, when the cohort is below the small-cell threshold.
Auto check-ins	The share of check-ins captured by event QR.
Avg outcome	Mean learning-outcome score across tagged MCQ items.

The four report cards

Card	Shows	Own CSV
Per-week completion funnel	Total enrollments and the count of students completing each week, as a funnel.	Download participation report (CSV)
Attendance capture	Check-ins by method, Auto (event QR) versus Manual / staff, with the automatic share as a percentage. A data-quality note says how many manual check-ins are legacy self-reports versus audited overrides.	Download attendance report (CSV)
Engagement	Content views by type (Tips after scan, Week details) and guide chat sessions, per challenge.	Download engagement report (CSV)
Learning outcomes	Mean score by learning-outcome tag, including hand-overridden scores. Reflections never contribute a score.	Download learning-outcome report (CSV)

Freshness

The dashboard re-reads its numbers about every 30 seconds while you are looking at it and states how long ago they were read. If a read fails the numbers on screen stay and the stamp ages; after three failed reads it says No longer refreshing automatically — showing the last numbers we could read. Refresh reads immediately. Polling pauses while the tab is hidden and resumes with an immediate read when you return.

Exports

Export	Contents	Per student?	Audited?
Download all reports (ZIP) header, primary action	Participation, attendance, engagement, per-event and learning-outcome CSVs plus `MANIFEST.txt` naming each file and stating no row describes a single student. Each file is byte-identical to its standalone download.	No	No
Export prize list (CSV) More exports	The grand-prize roster: one row per student who completed every required week. Re-exporting after a student's final required check-in adds them.	Yes	Yes
Export weekly prize list (CSV) More exports	The weekly drawing list: one row per student per week they checked in to, with the check-in time. Ignores the Required flag; weeks do not gate each other. A challenge with no check-ins yields a header-only file.	Yes	Yes
Export engagement detail (CSV) More exports	One row per enrolled student, including those with nothing done (zeros, blank timestamps): required weeks completed, check-ins by method, reflections submitted, MCQ mean (blank if none), prize-eligible flag (agrees with the prize list).	Yes	Yes
Export per-event report (CSV) More exports	One row per week, ordered by week number, including weeks nobody attended: activity type, location, window times, completed count, method split (and the verified-override versus legacy split within manual), content views, median hours to first check-in.	No	No
Per-card CSV buttons	The figures on that card, as shown.	No	No

The two prize files describe different populations on purpose and never reconcile with each other: a student who attended one week is in the weekly file and not in the grand-prize file. Re-exporting the same challenge with no new data produces a byte-identical file, so a list you pulled for a drawing can be reproduced later.

Small groups are hidden, not zeroed. Wherever a group is smaller than the small-cell threshold (a week completed by very few students, a tiny prize-eligible cohort, a rarely answered outcome tag), the figure is shown blank and flagged suppressed on screen and in CSVs. A suppressed per-event row also hides its method columns. An unanswered outcome tag reports a genuine zero and is distinguishable from a suppressed one.

Themes

Route: /admin/themes

A theme is the semester's look. Changing it is configuration: no code, no deployment. The built-in CSUB theme is the default; any theme you create is selectable on a challenge.

The library

Each theme is listed with its name, slug, a strip of its editable colour swatches, and how many challenges use it (Not in use when none). Preview and Edit sit on each row.

Create a theme

Press New theme.
Name (e.g. Spring Wellness) and Slug (e.g. spring-27; lowercase letters, digits and hyphens only, checked in the form before anything is sent).
Generate the palette:
- Start from a theme: copies every colour, font, art and copy setting from the theme you choose, for you to tweak.
- Derive from a source color: pick one Source color; the app generates the full Material palette from it (surfaces, containers, outlines and the hero gradient all follow), with text contrast handled for you. The live preview repaints as you pick.
Press Create theme. It appears in the library and in the Builder's Theme dropdown.

Edit a theme

The Theme editor (also reachable from a challenge's Edit theme button in the Builder) shows:

Four colour controls, each captioned in plain language with what it paints: the primary colour, the secondary colour, and the hero gradient's top and bottom. By default Hero top and bottom follow Primary; untick it to choose both stops yourself. A theme whose hero was hand-picked stays hand-picked; the app never silently regenerates it.
A note that the remaining palette roles carry over from the source theme.
App title and Tagline (Shown to students under the countdown), Copy tone, Logo URL, Hero art URL, and Guide persona (unused while the guide is disabled).
A live preview panel (app title, tagline, the three button styles and a progress card) that repaints from your unsaved changes. It is scoped to the panel; the admin screen around it keeps its own colours until you Save theme.

Where the theme applies. Everything after sign-in, for students and staff alike, follows the live challenge's theme and switches on the very next request after you change it. The sign-in screen is the exception: it is permanently CSUB blue and gold, so the front door always reads as Student Health Services.

The student's passport

What a student sees, so you can answer their questions. The passport is phone-first and can be installed to the home screen; on a desktop it gains a left rail (Passport · My QR · Get help · Sign out) and a two-column week grid.

Sign in and join. Sign in with campus SSO on the fixed CSUB sign-in screen. A current student lands on a page reading Verified current student with a Join button for the live challenge. Joining creates their enrollment. Someone who is not a current student sees You're not eligible to join; with no live challenge, No active challenge yet — check back soon and Check for a challenge to join.

Passport home. A top bar with the SHS mark and the My QR action; a themed hero with the app title, the countdown (3 of 7 weeks complete), the tagline and the eligibility pill (Prize eligible / Not yet eligible, with Complete every required week to enter the drawing); the week tiles with their status; a Scan button floating bottom-right; a reminder banner when staff have sent one.

Week sheet. Tapping a week shows When, Where and Prize, then Check in at event (or Catch up — check in on a missed week). Both open the scanner; neither completes anything by itself. A field for the backup code (e.g. WK4-7291) is on the scan sheet. After a check-in: Check-in complete, an SHS-written tip for the topic that notes their remaining progress, and Take the knowledge check if the week has items.

My QR. The student's personal passport QR with a short code underneath (e.g. WP-7F3A-92) and the caption that it is tied to their session, carries no ID number and no PHI, and is what staff scan on the Verify screen. Both rotate automatically.

Get help now. Always available from the passport (and the desktop rail), regardless of any other setting: crisis resources with 988, campus counseling and the SHS front-desk contact. The conversational wellness guide is disabled for the pilot; crisis resources are not.

Offline and updates. With no connection the passport shows You're offline and the last-synced progress; scanning and submitting answers need a connection and say so, recording nothing until reconnected. When a new version of the app is deployed, a returning student gets it before they start; a student mid-session is told a new version is available and chooses when to apply it.

Messages a student may ask you about

They see	It means	What to do
Already completed	They already have a check-in for that week.	Nothing; it was not double-counted.
This code is no longer valid, ask the attendant	An old poster, a past semester's code, a deleted task's code, or a forged code.	Show them the current Live event QR or read out the backup code.
A prompt to rescan the current code	The token they scanned had rotated out.	Have them scan again; the screen has already refreshed.
Couldn't check in / Check-in failed. Please try again.	A network or server error during the check-in.	Retry; if it persists, verify them on the Verify screen or mark complete with a reason.
Connection required	They are offline.	Reconnect and retry; nothing was recorded.
This display link has ended, ask the attendant (on the table's own tablet)	The display link was revoked, or the week's window closed.	Ask an admin for a new link from the Live event screen.
Not yet eligible after finishing a week	At least one required week is still incomplete.	Check their passport for weeks marked missed; catch-up sessions still count.

Privacy and audit

The app is built to hold as little about a student as possible and to leave evidence for everything staff do to a student's record.

Identity. Only an opaque SSO subject and the affiliation the campus asserts are stored. No names, no 9-digit IDs, no passwords, no health information. Every report, export and screen identifies a student by that subject only.
No student text leaves the server. Reflections and quiz answers are stored and read by staff; nothing a student writes is sent to any AI model. Post-check-in tips are SHS-authored template text.
Aggregation. Reports are aggregated and small cells are suppressed (blank and flagged, never zero). Reports are accessible to the admin role only, and only for your own campus.
Export ledger. Each per-student export (grand-prize list, weekly prize list, engagement detail) writes an audit row recording the admin, the challenge and the row count, filed under its own export kind. Aggregate downloads and the ZIP bundle do not. A refused export records nothing.
Check-in audit trail. Every manual add, change or removal records who, when, why, the student, and the prior state, and survives the deletion of the student record it concerns.
Notification audit. Every send, edit and skip records the deciding admin and the time.
Security events. Sign-in success and failure (with the reason, never the claimed identity or IP), sign-out, expired sessions, refused admin requests, rate-limit trips, display links being issued, revoked or refused, and rehearsal mode being entered, exited, reset or refused are recorded, retained for a fixed period, and exportable per campus by an admin. A rehearsal event names the admin who acted, never the rehearsal student.
Abuse controls. Check-in and sign-in endpoints are rate-limited per client; a real event's burst of hundreds of distinct students is unaffected. Display links are limited both per link and per device, so a tablet left on a link that has ended cannot poll without bound.

See also the Privacy & Data-Handling Notice.

Troubleshooting

I published and students still see last semester's challenge. Only one challenge is live. Check the Builder list: if the new one is badged Not live, the old one is still winning the live slot. Archive the old one, or re-publish the new one and accept the displacement dialog.

A week shows as locked on the student's phone but the event is today. Check the week's window dates and, if set, its start time; status follows the campus clock to the minute when times are set. A scan of that week's QR is accepted even while it reads locked, so the event can proceed. Fix: edit the task's window or times in the Builder; the change is live immediately.

The student's camera cannot read the projected QR. Read out the backup code beside the QR; they type it on the scan sheet (any case, hyphen optional). Or scan their My QR on the Verify screen and confirm the task.

Someone attended but has no phone. Open the week's check-in panel, press Mark complete, enter their SSO subject and a reason. It is recorded as a manual check-in with you as verifier.

Mark complete says the student is already checked in. A check-in already exists for that week, possibly from a scan you did not see. Use Remove (with a reason) then re-add only if the existing record is wrong.

The Live count is not moving. Confirm you opened Live on the right week and that the challenge is the live one (codes for a Not-live or archived challenge are refused). Students must be enrolled: a non-enrolled student is told to join first.

A number on Reports is blank with a "suppressed" flag. The group is below the small-cell threshold and is hidden on purpose. It will appear once the group is large enough. The CSV shows the same blank.

Reports says it is no longer refreshing. Three consecutive reads failed; the last good numbers stay on screen. Press Refresh. If it keeps failing, the API is unreachable; contact ITS.

The prize list and the weekly prize list do not add up. They are different populations by design: the grand-prize list is students who completed every required week; the weekly list is every student for every week they attended, required or not.

A reminder I sent is not on a student's passport. Check that the student is enrolled in that challenge, that the challenge has notifications enabled and is not archived, that the reminder was sent (not skipped), and that it is less than 14 days old. A student who dismissed it will not see it again.

I cannot delete a challenge. Only an untouched draft can be deleted. Anything that was published or has student data must be archived instead; the refusal names what blocks it.

A colleague signed in and got the student passport, not the admin app. They are not in the campus group mapped to the admin role. Ask ITS to add them; it takes effect on their next sign-in.

The theme I picked shows on the passport but not on the sign-in page. By design. Sign-in is always CSUB blue and gold; the theme applies to everything after sign-in.