Wellness Passport — product walkthrough

A guided tour of the SHS Digital Wellness Challenge Passport, told as one semester from set-up to the prize drawing. Each stage pairs what SHS staff do on the admin screens with what a student sees on their phone at the same moment.

Written for CSU Bakersfield Student Health Services staff. For a screen-by-screen reference — every control, every field, and troubleshooting — see the staff manual.

How to read this

Every stage below has two halves:

Staff — what you do in the admin app (desktop or phone).
Student — what the student sees in their passport at that point.

Quoted blocks record what the app refuses to do, and why. Those refusals are deliberate product behaviour, not bugs: they are what keeps attendance numbers honest and student progress intact.

Stage 1 — Access

Before anything else. Everyone signs in with campus SSO. Staff get the admin role from a group, not a password.

There are no accounts to create inside the app. ITS maps a campus group (for example shs-wellness-admins) to the admin role; anyone in that group sees the admin app after signing in, everyone else sees the student passport.

Open the app, choose Sign in with campus SSO, and authenticate with your campus credentials. Because your group is mapped to the admin role, you arrive on the Challenge Builder with a navigation rail down the left:

Builder · Reports · Verify · Notify · Themes, plus Sign out.

Need another staff member to have access? Ask ITS to add them to the mapped group. They get the role on their next sign-in, with no change to the app.

What the app refuses. A student who types an admin URL is sent back to their passport, and any direct call to an admin function is rejected. Every sign-in, sign-out, expired session and refused request is written to a security-event ledger you can export from the app, scoped to your campus.

Student — the front door is always CSUB blue and gold

Whatever theme the semester is using, the sign-in screen stays fixed in institutional CSUB colours, headed SHS Wellness Passport with the line An official CSU Bakersfield Student Health Services program.

After SSO, a current student lands on the join screen: the challenge's name and tagline, how many weeks it has and how many are required, its dates, the Grand-prize drawing card and Verified current student, above a Join the … button. On a computer the same screen opens as two panels, the themed challenge beside the join step. SHS stores only an opaque SSO subject — no name, no 9-digit ID, no health information.

Someone who is not a current student sees For current students instead. If nothing is published yet they see No active challenge right now, with Refresh.

Stage 2 — Build

Weeks before launch. Author the semester's challenge by hand in the Builder.

A challenge is a named, themed, multi-week program. Each week is one task with an event window; optional knowledge checks and reflections hang off a week. Nothing here is drafted by a model: staff write every word students read.

Staff — from blank draft to a full week list

New challenge: give it a Challenge name, Semester (e.g. Fall 2026), Start date, End date and a Theme. It is saved as a draft.
+ Add task (at the top of the challenge) once per week: Title (e.g. Week 1 – Vision Check), Caption, Activity type, Location, Window start / end, optional Start time / End time, Prize, and Required task, whose Counts on its own box decides whether the week counts toward grand-prize eligibility. A semester built as a map rather than a run of weeks? + Add group gathers weeks into groups that each ask for N of M (see the staff manual's Groups).
Reorder weeks with the Move up / Move down buttons on each row. They work by keyboard and on a phone.
Add item on a week to attach a Multiple choice (MCQ) question (prompt, at least two options, answer key, learning-outcome tag) or a Reflection prompt (with an optional What to look for note for reviewers).
Short on time? Duplicate last semester's challenge: it becomes a fresh, independent draft with the same weeks, quiz items and theme under a new name and semester.

What the app refuses. An end date earlier than its start date (for the challenge or for any week). A start or end time without a date. An MCQ whose answer key does not match one of its options, or that has fewer than two options. A single-day window, and a week with no window at all, are both fine.

Student — nothing yet, and that is the point

A draft is invisible to students. Until you publish, a student at your campus keeps seeing last semester's live challenge, or the No active challenge screen if there is none.

What you write in the Builder is exactly what they will read: each week becomes a card showing its activity type, title, dates and location. Tapping it opens the week's sheet, which adds the caption and the Location, Date window and Weekly prize rows.

Stage 3 — Skin

Any time before publishing. Give the semester its look with a theme, then preview as a student.

A theme re-skins the whole student app: colours, app title, tagline, logo and hero art. It is a configuration change, never a code change, so a new semester look is something SHS does on its own.

Staff — Themes library, then Preview as student

Open Themes on the rail. The library lists every theme with its name, slug, colour swatches and how many challenges use it. CSUB is the built-in default.
New theme: give it a Name and a Slug (lowercase letters, digits and hyphens, e.g. spring-27), then choose how to Generate the palette: Start from a theme (copies an existing theme's full palette to tweak) or Derive from a color (builds a complete, coherent Material palette from one colour you pick with the swatch or type as a hex value). The slug is checked as you type.
Edit the theme: four colour controls, each captioned in plain language with what it paints, plus App title, Tagline (shown on the join screen), Copy tone, Logo URL, Hero art URL, and Labels, the words the app counts with (e.g. seal / seals, location / locations). By default the hero gradient follows Primary; untick Hero top and bottom follow Primary to pick both stops by hand. A live preview beside the controls repaints as you change colours, before you press Save theme.
Back in the Builder, set the challenge's Theme (the Theme button on the challenge opens it in the editor) and press Preview as student. The preview renders inside a phone frame exactly as a student would see it, writes nothing, and has check-in disabled. Back to builder returns you.

Good to know. The sign-in screen never takes the theme: it is always CSUB blue and gold. Everything after sign-in (passport, admin screens) follows the live challenge's theme.

Student — what the preview shows you

The progress card in the theme's colour shows the app title and the countdown (0 of 7 complete, 7 remaining). Below it, the Grand-prize drawing card says what is left to do, then Your passport lists a card per week with its status label.

A week reads Available only inside its own date window, Upcoming before it, and Catch up (still completable) after it closes; a finished week reads Complete.

Stage 4 — Publish

Launch day. Publish, and exactly one challenge goes live for the campus.

A campus has one live challenge at a time. The Builder tells you which one students are seeing, and will not let a publish silently knock a running challenge out from under enrolled students.

Staff — press Publish challenge, read the badge

Open the draft. At the foot of the Groups block it says Ready to publish. (or what is blocking it); press Publish challenge. If nothing is live at your campus, it publishes at once and the list marks it Live.
If another challenge is already running, with enrolled students and recorded check-ins, the publish is refused and the dialog names that challenge, its enrolled-student count and its check-in count. Choose Publish anyway only if you really mean to replace it, or Cancel.
A second published challenge that does not win the live slot is marked Not live. Editing it shows a note that the change will not reach students yet.

Why the guard exists. Replacing the live challenge mid-run would change what every enrolled student sees and which event codes validate. A refused publish leaves every student's progress, and every printed event QR, exactly as it was.

Student — join, and the passport appears

From the moment you publish, a current student who signs in sees Join the … for this challenge. Joining creates their enrollment and lands them on the passport, with every week showing its real status for today's date.

Students can install the passport to their home screen like an app. When you ship an update later, a returning student gets the new version before they start; a student mid-session sees A new version is ready. with Reload, and chooses when to apply it.

Stage 5 — Event

Every event, every week. The core loop: show the event QR, students scan, the week gets its stamp.

A student's own check-in is always a scan of an event credential. There is no "mark complete" button on the student side. Each week runs on one of two credentials, chosen in the task form: the rotating code on a staffed screen, where every Automatic check-in in your reports is a student who was physically at the event, or the printed poster for a location nobody staffs, where check-ins are self-reported within the event's hours and the reports count them separately as Poster.

Staff — open Live on the week's row

In the Builder, press Live on the week's task row. The Live event screen shows the Event QR large enough to project or hold up, and a short backup code beside it (e.g. WK4-7293).
The QR is a signed token that rotates every 30 seconds on its own (Code refreshes automatically), so a photo of it shared off-site stops working almost immediately. Rotate code forces a fresh one.
Watch Checked in — live climb as students scan, with a Recent check-ins list beneath it.
A student whose camera will not cooperate? Read out the backup code. It is accepted typed in any case, with or without the hyphen, and stays valid across one rotation boundary so nobody is caught mid-word.

A week with no table. Choose Printed poster in the task form (the default for a new week; it needs a window end). On Live, press Print poster, print the letter-size sheet and post it at the location. Copy check-in link and Download QR give you the same code for an email or a flyer. The code works only during the week's window; if a poster leaks, Reprint and void old copies kills every earlier sheet at once, and changes the typed backup code printed on it. A poster week has no rotating code and no display link, and catch-up after the window is by hand.

Higher-assurance option. For an event where you want to see whom you are crediting, use Verify on the rail instead. One card walks you through it: scan the student's My QR, choose the week in Task to confirm, press Confirm check-in, and it reads Confirmed. That check-in is recorded with method staff and your identity as the verifier.

Student — scan, stamp, tip

The student taps Scan (or Check in at event on the week sheet), points the camera at your QR, and the week flips to complete. They can also skip the app and point their phone's own camera at the projected code: it opens the app, signs them in if needed, and checks them in the same way. They immediately see Checked in!, their updated count, and an SHS-authored tip for that topic under Your next step, with Take the knowledge check only if you attached questions to that week.

What they see when something is off. A second scan: You've already completed this week (no double count, drawn as a success). A code from a past semester or a deleted week: That code is for a different event or week. A friend's My QR: That looks like someone's personal QR. A typed code that matches nothing: No event matches that code. A code older than its rotation window: a prompt to rescan the current code.

Student — the poster, camera first

For a poster week the student never has to open the app first. They point their phone's camera at the poster's code and tap the link; signed in, Checking you in… becomes the same Checked in! sheet and tip. Not signed in, the sign-in screen says Sign in to finish checking in, and the check-in finishes on its own afterwards. The in-app Scan button reads the poster too. A camera that will not read the sheet is what the ruled box under the QR is for: Scan, Enter code manually, and type the code printed there.

What they see when something is off. Before the window: This event isn't open yet. It opens Thursday, Oct 1 at 10:00 AM. After it: This event has ended. If you were there, Student Health Services can check you in. A voided sheet: This poster has been replaced. Look for the newer copy at the location.

Stage 6 — Between

Between events. Reminders go out only when you say so, and missed weeks stay open.

The app drafts reminders for you on a schedule, but nothing reaches a student until a staff member sends it. Reminders arrive as a banner inside the passport, never as a push notification.

Staff — work the Notify queue

Open Notify. Roughly every 15 minutes the app proposes a new-week reminder the day before a week opens, and an expiring reminder as the challenge nears its end. The queue is one list: each row shows its audience (All enrolled (214)), when it was proposed or went live, and a chip, Awaiting decision, Scheduled or Skipped. Rows awaiting a decision sit at the top.
Choose Send (publishes to every enrolled student's banner immediately), Edit (change the title and body, then Save and send), or Skip (never sent).
Need your own message? + New notification: pick the challenge, write a title and body, choose the audience (Everyone enrolled or Only students with an incomplete current week), and Send now or Schedule for a date and time.
Every decision is recorded with who made it and when. A challenge with notifications turned off, or one you have archived, sends nothing even if approved.

Catch-up sessions. A student who missed a week can still complete it at a later event, or at a make-up session where you show that week's QR again. The catch-up still counts toward their grand-prize eligibility. A reminder aimed at students with an incomplete current week is the easy way to invite them.

The banner shows only for students enrolled in that challenge; its Open goes straight to the week it is about, and dismissing it sticks across reloads.

Opening a missed week says the window has passed but it still counts toward their passport and the grand-prize drawing (only the weekly raffle entry has closed), and offers Catch up — check in, which launches the scanner. The passport itself never completes a week.

Stage 7 — Fix

When the real world intervenes. Correct a check-in by hand, with a reason, and leave a trail.

Phones die and students show up without them. An admin can add or remove a completion, but every such change records who did it, when, why, and what the record looked like before.

Staff — the check-in panel on any week

From the Live event screen (Check in a student) or the week's Check-ins in the Builder, open the week's check-in panel. The Check-ins tab lists every student checked in for that week, each named by their SSO subject.
Check in a student, pinned at the bottom of the panel however long the list is: the list gives way to a short form. Enter the Student SSO subject and a Reason (Why is this being marked by hand?) and press Check in. The check-in is recorded with method manual and you as the verifier, and appears at the top of the list.
Remove on a row asks for a reason too, and keeps the prior state for audit.
The Audit trail tab shows every change with the student it was about. Show history for narrows it to one student.

Close the panel from the ✕ at the top or with Escape. Escape first cancels any half-typed reason, then closes; tapping outside does not close it, so a stray tap at a crowded event cannot lose your note.

Refused. Checking in a student who already has a check-in for that week: use Remove, then re-add. Every manual check-in after the pilot's launch carries a staff verifier; your attendance report separates these from any legacy self-reported rows.

Student — their passport simply updates

A manual completion shows on the student's passport as complete like any other, counts toward their progress and prize eligibility, and if you remove an erroneous one the week returns to its real status. The student never sees the audit trail; only staff do.

Stage 8 — Review

As responses come in. Quiz answers score themselves; reflections are read by a person.

Multiple-choice answers are scored the instant a student submits. Reflections are never scored by anything, and no student-written text is ever sent to an AI model; staff read them and mark them reviewed.

Staff — two review panels on the challenge screen

Open the published challenge in the Builder. Below the weeks sit Reflection review and MCQ score override, each collapsed to a count line (items, responses, how many still unreviewed or hand-scored) so a semester's worth of answers does not load until you ask.
Show responses on a reflection item lists only the unreviewed ones, with your What to look for note above them. Read, then Mark reviewed; the row leaves the queue. Show reviewed (N) brings them back if you need to re-review.
If a quiz question turns out to be faulty, expand the MCQ item and hand-set a Score (0–1) on a response. The override is logged with your staff id and a timestamp, and the learning-outcome report reflects it.

Student — instant feedback on the quiz, none on the reflection

An MCQ answer comes back immediately as Correct — Nice work. or Not quite — the correct answer is "…"., naming the right option. A reflection is acknowledged with Saved. Reflections aren't scored — SHS staff read them and mark them reviewed. and nothing more — there is no score for them to see, because none is ever computed.

Stage 9 — Report

Any time, and at the end. Reports refresh on their own; the prize lists are one click.

The dashboard is built for the question "how is the semester going?" and for the two drawings at the end: a weekly drawing for everyone who attended a given week, and a grand prize for students who completed every required week.

Staff — Reports on the rail

Pick the challenge at the top (the live one is selected by default; archived ones are still reportable). On a desktop, four tiles summarise Enrolled, Prize-eligible, Auto check-ins and Avg outcome.
Four cards: Per-week completion funnel (named by your theme's group word in a grouped challenge, e.g. Per-location completion), Attendance capture (Auto (event QR) vs Manual / staff), Engagement (a Weekly actives bar per week — the share of enrolled students who checked in that week — then content views, tips after scan and week details) and Learning outcomes (mean score by outcome tag). Numbers refresh automatically about every 30 seconds, the line under the title says how long ago they were read, and Refresh in the header reads them now.
Download all reports (ZIP) is the primary action: the six aggregate CSVs plus a manifest, no per-student rows.
More exports holds the per-student files: Export prize list (CSV) (grand prize), Export weekly prize list (CSV) (one row per student per week attended), Export engagement detail (CSV), and Export per-event report (CSV).

Privacy is built into the numbers. No report or export ever contains a name, campus ID or health information; per-student files identify a student only by their opaque SSO subject. Any group smaller than the small-cell threshold is shown blank and flagged suppressed, never as a misleading zero. Each per-student export writes an audit row (who, which challenge, how many rows) as FERPA evidence; aggregate downloads do not.

Student — "you're entered in the drawing"

Eligibility is derived, not granted: the moment a student completes their last required week (including by catch-up), their Grand-prize drawing card reads All 7 required weeks complete — you're entered in the drawing. and they appear in the next grand-prize export, exactly once.

A student who attended only some weeks still appears in the weekly drawing list for each week they attended.

Stage 10 — Retire

After the last drawing. Archive the semester; keep every record; start the next one from a copy.

A challenge that ran is archived, never deleted. Archiving takes it out of students' view and mutes its reminders while keeping every check-in, response and audit row available to reports.

Staff — Archive, Show archived, Restore

On the finished challenge press Archive and confirm Archive this challenge? You can restore it later. It leaves the default list; Show archived reveals it.
Reports still work for it by selecting it on the dashboard. Nothing about its history is lost.
Changed your mind? Restore republishes it, with the same displacement guard as Publish (Restore anyway if it would replace the current live challenge).
Next semester: Duplicate the archived challenge into a new draft, adjust the dates and weeks, and you are back at stage 2.

Delete is only for untouched drafts. A draft nobody ever joined can be deleted (its name and semester become reusable). Anything that was published or has student data cannot be deleted; the app refuses, names what blocks it, and offers Archive instead.

Student — back to "No active challenge right now"

Once the only published challenge is archived, students see No active challenge right now until the next one is published. Their installed app is not a dead end: it offers a way back to the landing screen and to join when the next challenge appears.

Their past progress is retained on your side for reporting, never shown as a live challenge again.

Three things worth remembering about how it is built

These shape how you will answer questions from students, ITS and leadership.

It stores almost nothing about a student. Only an opaque SSO subject and the affiliation the campus asserts. No names, no 9-digit IDs, no passwords, no health information. Reflections and quiz answers stay on your server and are never sent to an AI model.

Attendance is evidence, not self-report. A student can only complete a week by scanning a rotating event QR or being verified by staff. Every check-in records its method, so the "Automatic" share in your attendance report means what it says.

Staff are always in the loop. Nothing reaches a student's screen (reminders, broadcasts) and nothing changes a student's record (manual check-ins, score overrides) without a staff decision that is logged with who, when and why.

The Get help now crisis resources remain available to students at all times. For the control-by-control reference and troubleshooting, see the staff manual.