Skip to content

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.

Staff — sign in, land on the Builder

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 sees a Join button for your live challenge, above a note that SHS stores only an opaque SSO subject — no name, no 9-digit ID, no health information.

Someone who is not a current student sees You're not eligible to join instead. If nothing is published yet they see No active challenge yet, check back soon.

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

  1. 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.
  2. Add task once per week: Title (e.g. Week 1 – Vision Check), Caption, Activity type, Location, Window start / end, optional Start time / End time, Prize, and the Required task checkbox that decides whether the week counts toward grand-prize eligibility.
  3. Reorder weeks with the Move up / Move down buttons on each row. They work by keyboard and on a phone.
  4. 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).
  5. 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: the task title becomes the week tile, the caption becomes the short description under it, and the window dates and location appear on the week's detail sheet as When and Where.

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

  1. 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.
  2. 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 source color (builds a complete, coherent Material palette from one colour you pick).
  3. Edit the theme: four colour controls, each captioned in plain language with what it paints, plus App title, Tagline, Copy tone, Logo URL and Hero art URL. 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.
  4. Back in the Builder, set the challenge's Theme 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, guide) follows the live challenge's theme.

Student — what the preview shows you

The themed hero shows the app title and tagline you wrote, the progress countdown (0 of 7 weeks complete), and the prize-eligibility pill. Week tiles show each week's status.

A week is available only inside its own date window, locked before it, and becomes missed (still completable) after it closes.

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, read the badge

  1. Open the draft and press Publish. If nothing is live at your campus, it publishes at once and the list marks it Live.
  2. 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.
  3. 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 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 is told a new version is available 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 the live event QR. There is no "mark complete" button on the student side, so every Automatic check-in in your reports is a student who was physically at the event.

Staff — open Live on the week's row

  1. 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-7291).
  2. 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.
  3. Watch Checked in — live climb as students scan, with a Recent check-ins list beneath it.
  4. 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.

Higher-assurance option. For an event where you want to see whom you are crediting, use Verify on the rail instead: 1 · Scan their QR (the student opens My QR on their phone) and 2 · Confirm the task. 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 immediately get an SHS-authored tip for that topic that acknowledges their remaining progress, and a prompt to Take the knowledge check if you attached one.

What they see when something is off. A second scan: Already completed (no double count). A code from a past semester or a stale poster: This code is no longer valid, ask the attendant. A code older than its rotation window: a prompt to rescan the current code.

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

  1. 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. Each sits under Awaiting your decision with the audience size: Send to 214 enrolled students?
  2. Choose Send (publishes to every enrolled student's banner immediately), Edit (change the title and body, then Save and send), or Skip (never sent).
  3. Need your own message? New broadcast: 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.
  4. 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.

Student — a banner, and a week that says "still open"

The banner shows only for students enrolled in that challenge, and dismissing it sticks across reloads.

Opening a missed week shows Catch up — check in, which launches the scanner; the student is told they need a staff-issued code, because 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

  1. From the Live event screen (or the task 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.
  2. Mark complete: enter the Student SSO subject and a Reason (Why is this being marked by hand?). The check-in is recorded with method manual and you as the verifier.
  3. Remove on a row asks for a reason too, and keeps the prior state for audit.
  4. 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. Marking a student complete 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

  1. 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.
  2. 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.
  3. 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 You answered this correctly or You answered this incorrectly. A reflection is acknowledged with Reflection submitted 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

  1. 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.
  2. Four cards: Per-week completion funnel, Attendance capture (Auto (event QR) vs Manual / staff), Engagement (content views, tips after scan, week details, guide sessions) and Learning outcomes (mean score by outcome tag). Numbers refresh automatically about every 30 seconds, and a stamp says how long ago they were read.
  3. Download all reports (ZIP) is the primary action: the five aggregate CSVs plus a manifest, no per-student rows.
  4. 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 — the pill turns gold

Eligibility is derived, not granted: the moment a student completes their last required week (including by catch-up), their passport reads Prize eligible 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

  1. 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.
  2. Reports still work for it by selecting it on the dashboard. Nothing about its history is lost.
  3. Changed your mind? Restore republishes it, with the same displacement guard as Publish (Restore anyway if it would replace the current live challenge).
  4. 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 "check back soon"

Once the only published challenge is archived, students see the No active challenge screen 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 conversational wellness guide ships disabled for the pilot; 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.