Technical reference. For task-based help, see the corresponding user guide.

Documentation status: complete for the current implementation

Reviewed: 2026-07-21

Primary users: authorized assigned coaches

Surfaces: mobile coach workspace and platform API

View as family lets a coach inspect and, where explicitly permitted, work in the mobile-first family experience for one assigned family. It reuses branded family screens but carries a trusted coachView subject context, a persistent visual banner and assignment-derived permissions.

It is not authentication impersonation. The session actor remains the coach, the subject remains the family, writes are attributed to the coach, and every API call resolves authorization again.

1. The coach opens a current family from /coach or /coach/families.
2. The root route is /coach/families/:familyId/view-as.
3. The family home displays a Viewing as / Coach view as mode banner with the family name, family timezone and Exit view.
4. Organization branding is resolved for the subject family so the coach sees the intended family-facing colour/logo context.
5. Entering view-as can mark the roster's general activity summary seen; notification-feed seen state is independent.

The selected baby's identifier is carried as ?babyId=… where the destination supports it. Tracking actions created from the family hero also append that identifier, avoiding an accidental switch to another baby.

The family summary returns a ResolvedAccessContext containing:

• the real coach session;
• subjectUser for the family;
• mode: coachView;
• the matching assignment and organization;
• resolved family premium state; and
• explicit booleans for read, write, support-date, revoke and analysis permissions.

The mobile CoachBillingRouteGate also checks coach subscription state around these routes. A client-side gate improves feedback; it does not replace subject authorization.

1. Family activities can be read only when canReadActivities is true.
2. Coach-created and coach-edited activity mutations retain the coach as actor/update source for audit and analytics.
3. Coach view cannot write a family-facing activity note. An attempted non-empty family note is denied server-side.
4. Existing family notes can be shown as family-provided context.
5. Coach-private baby/activity notes use separate endpoints and UI, are scoped to the genuine coach and are never merged into the family note. See Feature 19.
6. Realtime activity changes cause the relevant view to refresh, with conflict handling in the underlying activity screens.

1. Questionnaires use the coach-family collection endpoint but the form is forced read-only.
2. Sleep plans use the published-only collection, matching what the family can see rather than the coach authoring draft/history.
3. Allergy ladders use family subject permissions; write controls depend on canWriteActivities.
4. Analysis requires both assignment permission and premium access.

The view-as menu currently links to /coach/families/:familyId/reminders, but RemindersScreen receives no family identifier and reminders are stored locally on the current device. This route must not be interpreted as access to the family's reminders. It is a shell/navigation reuse, not a trusted family-reminder record view.

Coach view-as is treated as a synthetic family context by the mobile chat provider. Chat inbox/composer UI is hidden there, and message sending must occur as the genuine coach from the coach chat workflow. This prevents a coach-view screen from appearing to speak as the family.

1. A coach can enter only a family assigned to that same coach through an active assignment.
2. Active organization membership, organization state, coach billing and support record access are enforced by the platform.
3. Expired/revoked relationships cannot regain records through a bookmarked view-as URL.
4. A route family identifier is untrusted input. The API resolves the matching assignment and rejects mismatches.
5. The visible banner is necessary user context but is not the security control.
6. Family-facing notes remain family data; coach-private notes remain per-coach private data.
7. Coach view-as is separate from the super-admin's owner-view-as-coach session. Neither is allowed to bypass feature-specific genuine-coach restrictions such as private notes or chat participation.

1. The banner always identifies family view-as and offers an explicit exit.
2. The actor remains the coach and the subject family identifier is verified on every API operation.
3. Selected-baby context survives eligible view-as navigation.
4. Read/write/analysis controls follow the returned permission booleans and backend denial remains authoritative.
5. Questionnaires are read-only and sleep plans are published-only in view-as.
6. A coach cannot add or overwrite a family-facing activity note.
7. Private notes remain visually/data-model separate and chat remains unavailable in the synthetic view-as context.
8. The reminders route is not documented or represented as family reminder access.
9. An expired or revoked assignment cannot be opened from a saved URL.

• mobile-web/src/App.tsx
• mobile-web/src/components/AppShell.tsx
• mobile-web/src/components/FamilySideMenu.tsx
• mobile-web/src/routes/FamilyDashboard.tsx
• mobile-web/src/routes/ActivityTrackingScreen.tsx
• mobile-web/src/routes/AnalysisScreen.tsx
• mobile-web/src/routes/AllergyLaddersScreen.tsx
• mobile-web/src/routes/RemindersScreen.tsx

• platform/packages/shared/src/access.ts
• platform/apps/api/src/services/authorization-service.ts
• platform/apps/api/src/services/prisma-invite-flow-service.ts
• platform/apps/api/src/services/family-service.ts

• 07 — Activity tracking
• 09 — Analysis and trends
• 10 — Device reminders
• 11 — Allergy ladders
• 12 — Family questionnaires
• 13 — Published sleep plans
• 16 — Family caseload and support lifecycle
• 19 — Coach-private notes