Content plan queue

Whatever you advise here.

- **Patients, not clients** — all user-facing copy within Communication Hub must use the term 'patients' when referring to individuals receiving dental or healthcare treatment. The terms 'clients', 'customers', or 'contacts' must not be used in this context. This applies to filter labels, thread-list headers, context-type badges, and any instructional copy. This is consistent with the domain terminology of dental and healthcare practice. *(Confirmed by Harry during design review: 'You can rename clients to patients … because we're in the Dental world. It's always patients … not customer or client or yeah, it's always patients in this world, in the Dental world, or healthcare, I guess, generally.')*

**Manual 1-hour snooze control.**

A 'Snooze notifications for 1 hour' action is surfaced in the user's notification preferences or a quick-action area (e.g. a bell icon with a snooze option). Tapping/clicking this immediately suppresses all Communication Hub notifications for exactly one hour. The control:

- Shows a single, unambiguous label — **'Snooze for 1 hour'** — with no option to select a different duration.
- Does not appear as a toggle (which implies permanence); it appears as a time-limited action.
- Displays a visible 'Snoozed until [time]' indicator in the notification area for the duration of the snooze, so the user knows notifications are suppressed and for how long.
- Disappears (or becomes inactive) when quiet hours are already active via the rota (see below), since the mute is redundant.

For roles where the practice administrator has restricted mute capability, the 'Snooze for 1 hour' control is not rendered — it does not appear as disabled; it is absent.

**Quiet hours (rota-driven automatic suppression).**

Separately from the manual snooze, the system automatically suppresses all Communication Hub notifications for a staff member when they are outside their rota working hours (off-shift or on a scheduled lunch break). This is driven by the Rota Manager shift data already consumed by Staff App Mode for quiet-hours enforcement (see Rota Manager technical spec §6.3 Staff App Mode — Quiet Hours Contract). The user does not need to take any action for quiet hours; the system manages it automatically. When quiet hours are active, the notification area displays a subtle indicator such as 'Quiet hours active — notifications resume at [shift start time]'. *(Confirmed: Harry: 'have the quiet hours built, baked in, linked to the router [rota] … if they're off rota or on lunch, it just automatically doesn't notify them.')*

**Notification mute — 1-hour cap (authoritative rule).**

- A staff member MAY manually mute all Communication Hub notifications for a maximum of **one hour** during their rota working hours. No other mute duration is permitted via the self-service UI during working hours.
- After one hour the mute MUST auto-expire and notification delivery MUST resume immediately without requiring any user action.
- Indefinite / permanent muting of notifications by individual staff members is **not supported** for role-based work queues. The platform is work-critical and notifications are considered mandatory during working hours.
- Whether a staff member's role permits the 1-hour self-service mute is governed by role configuration in Access Manager. Practice administrators MAY restrict the mute capability for specific roles (e.g. front-of-house roles with a patient-facing queue responsibility) so that the mute option does not appear in the UI for those roles.
- The mute operates at the **global notifications** level (all Communication Hub notifications suppressed for the user for one hour), not at the individual channel level. A channel-level mute is not exposed in the UI.
- The mute state (active / inactive, expiry timestamp) MUST be stored per user session and MUST be honoured across all delivery surfaces (web, tablet, mobile) for the duration of the mute window.
- All mute activation and expiry events MUST be audit-logged with actor, timestamp, and expiry time.

*(Decided by Harry during design review: 'I would just say, for what, mute channel one hour only, don't give me any other options … take it out [the indefinite option] because this is a platform designed for work … we're giving them the option to snooze them temporarily up to an hour and it will reinstate after an hour.')*

**Reply-method selector placement.** The control for choosing the outbound reply channel (e-mail, WhatsApp, SMS, etc.) is embedded inside the compose area itself — it is not displayed as a separate row above or below the composer. This avoids a crowded toolbar and keeps reply-method selection contextual to the act of composing. The selector appears as a small control within the composer (e.g. a channel-type icon or dropdown at the leading edge of the input field). This applies to both the web portal and tablet compose surfaces. *(Confirmed during design review; earlier designs had the selector as a separate row which was considered too crowded.)*

## Per-Channel Settings

Each channel exposes a **settings panel** accessible via a cog/gear icon within the channel view. Settings are configurable by admin/privileged users only.

### Notification settings
- **Default: ON** for all channel members. Any new message in the channel triggers:
  - An in-app notification pop-up, AND
  - An activity feed entry (clicking it navigates directly to the message).
- Individual members may turn notifications off for a specific channel, but the default cannot be changed to off by end-users.
- Admin users may configure notification behaviour at the channel level (e.g. suppress all notifications for a low-priority channel).

### Member management
- Add/remove **individual users** to the channel.
- Add/remove **roles** — all current members of that role are automatically included. This is the preferred approach for most channels as it scales with staff changes.
- Both individual and role-based membership may co-exist in the same channel (e.g. a channel scoped to a role but with one ad-hoc individual added).

### General
- Edit channel name and description.

**Out of scope at launch:** channel-level third-party integrations, favouriting channels.

### Typing Indicators and Real-Time Presence Signals

Typing indicators are transient, real-time presence signals that communicate to all participants in a Conversation Thread that one or more other participants are actively composing a message. Communication Hub is responsible for receiving, buffering, and broadcasting typing-indicator events in real time across all connected clients in a thread.

#### Data Model

A TypingIndicator is an ephemeral signal, not a durable artefact:

```
TypingIndicator {
  ThreadId: string
  UserId: string
  StartedAt: timestamp
  LastActivityAt: timestamp
  IsActive: bool
}
```

Fields:
- **ThreadId** — the Conversation Thread to which the indicator belongs
- **UserId** — the staff member or patient ID of the composer
- **StartedAt** — timestamp when input began
- **LastActivityAt** — timestamp of the most recent keystroke or input event
- **IsActive** — boolean flag; true whilst the user is actively composing, false once input ceases

Typing indicators are **NOT persisted** to the Conversation Thread's message history or AuditTrail. They exist only in-memory during the active session.

#### Transport and Real-Time Delivery

Communication Hub MUST:
- Receive TypingIndicator events from connected clients via WebSocket or equivalent real-time transport
- Buffer the most recent TypingIndicator state for each active user in a thread
- Broadcast the aggregated TypingIndicator set to all other connected clients in that thread within 100ms of state change
- Clear a TypingIndicator from the broadcast set if LastActivityAt exceeds 5 seconds (user has stopped typing)

Clients (Web Portal, Tablet App, Mobile App, Staff App Mode) are responsible for:
- Emitting a TypingIndicator event every 500ms whilst the compose field has focus and contains characters
- Clearing the TypingIndicator (IsActive = false) when the compose field loses focus or is cleared
- Rendering the aggregated TypingIndicator set received from Communication Hub according to the

### Typing Indicators and Real-Time Presence Signals

When one or more participants are composing a message within a Conversation Thread, Communication Hub MUST surface a real-time typing indicator to all other participants in that thread. This affordance signals active composition and reduces perceived latency during multi-participant exchanges.

#### Behaviour and Visual Treatment

**Single composer** — When a single staff member or patient is actively typing, a prominent but non-intrusive indicator appears above the message compose area or at the base of the message history pane. The indicator displays: the composer's name or avatar, the word "typing…", and a gentle animated cue (e.g. three dots). The indicator remains visible for the duration of active input and disappears within 500ms of input cessation.

**Multiple composers** — When two or more participants are typing simultaneously, the indicator adapts to show either:
- A stacked list of names ("Alice and Bob are typing…") for up to three concurrent composers, or
- A aggregated count ("3 people are typing…") for four or more concurrent composers.

The visual treatment MUST remain calm and non-alarming; the indicator MUST NOT flash, pulse, or draw attention away from the message history itself, consistent with the Core UX Principle "Calm by default".

#### Technical Boundaries

Typing indicators are a **presentation layer only**. They do not create any durable record or audit event; they are transient signals. Communication Hub MUST NOT:
- Log typing indicator events to the audit trail
- Store or replay typing activity
- Use typing indicators to infer message intent or content

Typing indicators are sourced from the client-side composition state of each participant's device and MUST be transmitted in real time via Communication Hub's message transport layer (WebSocket or equivalent).

#### Scope and Availability

Typing indicators are available in:
- Direct Chats (1:1 internal staff and patient-facing)
- Cha

### Typing Indicators & Real-Time Presence

When a staff member or patient is actively composing a message within a thread or channel, Communication Hub MUST surface a real-time typing indicator to all other participants in that conversation. This affordance provides immediate visibility into who is composing, reducing duplicate efforts and clarifying conversation flow without requiring explicit status updates.

#### Display Rules

Typing indicators MUST:

- Appear inline within the message history, positioned above the message composer, visually distinct from sent messages
- Display the name(s) of the person(s) currently typing, updated in real time as typing begins and ends
- Persist for no longer than 3 seconds after typing activity stops; if typing resumes within that window, the indicator remains continuous
- Be read-only — participants cannot interact with the indicator itself; it is purely informational
- Scale gracefully when multiple participants are typing simultaneously — show up to 3 names inline, e.g. "Alice, Bob, and Carol are typing…"; if more than 3 are typing, use "[N] people are typing…" with the count updated in real time

Typing indicators MUST NOT:

- Appear on read-only threads (e.g. request-linked message histories post-conversion, CallThread transcripts, or Announcement reply contexts)
- Persist in the thread history; they MUST be ephemeral and must not be stored or logged as part of the conversation record
- Trigger notifications or sound alerts
- Reveal that a participant has begun typing but abandoned the message before sending (the indicator appears only when typing is actively occurring)

#### Architectural Considerations

Typing state is ephemeral and MUST be transmitted via a real-time pub-sub mechanism (e.g. WebSocket) rather than persisted to the database. Communication Hub MUST:

- Emit a `TypingStarted` event to all active participants in a thread when a staff member or patient begins composing
- Emit a `TypingStopped` event when t

**Role/team calendar association:**

Each Work Package MUST carry a `CalendarId` field referencing the role or team calendar to which it belongs. The system maintains one calendar per configured role or team (as defined in Access Manager). This association governs:

- Which calendar track the work package appears on in the overlay view.
- The colour-coding applied to the work package in multi-calendar overlay mode.
- Default visibility rules: a user whose role matches the work package's `CalendarId` sees it in their default calendar; other users see it only when the relevant calendar is enabled in overlay mode or they hold a manager-level permission.

Work packages assigned to a specific individual also carry the individual's personal calendar identity as `CalendarId` where applicable.

Inferred from Harry Leak: 'The way I see it is you've got a calendar for each role that we have configured in the back end… it will automatically go to the people that are assigned to that calendar.'

**Multi-calendar overlay (role/team calendars):**

The calendar view supports a multi-calendar overlay model, analogous to the shared-calendar model in tools such as Microsoft Outlook and Google Calendar. Each configured role or team (e.g. Dental Nurses, Front of House, TCO, Practitioners) has its own calendar track, colour-coded with a unique colour per role.

- **Default state:** Users see their own calendar (tasks and work packages assigned to their role or to them personally).
- **Overlay mode:** Users may enable overlay mode to see multiple team calendars simultaneously on a single view. Each team's items are rendered in the team's assigned colour, allowing managers to see where work overlaps or where teams are operating concurrently.
- **Filter / toggle:** Individual team calendars can be toggled on or off from a calendar list panel (analogous to the Outlook/Google Calendar sidebar), allowing the user to show all, show a subset, or return to their own calendar only.
- **Manager default:** Practice managers default to seeing all team calendars overlaid, with the option to filter down.

Harry Leak: 'You've got a calendar for each role that we have configured in the back end… you can see an overlay of all of those work packages on one screen… or you can turn them off and just see one or two, or it defaults to your own… role might be colour A, role B will be colour B — they overlay, so you can see where they cross over.'

#### Flow 15 — Drag-and-drop work package scheduling onto team calendar (Web Portal)

Inferred from Harry Leak's description of the intended scheduling workflow.

1. A manager opens the work package triage list — a centralised list of work packages that are due or need to be scheduled.
2. The manager opens or overlays the team's calendar (Daily or Weekly view).
3. The manager drags a work package from the triage list onto the calendar at the intended start time (30-minute increment precision).
4. The system creates a scheduled instance of the work package with the assigned team, start time, and calculated end time (based on configured duration).
5. The scheduled instance is immediately visible to all team members in their own calendar views.
6. The work package is removed from the unscheduled triage list once placed.

This workflow is the primary intended mechanism for converting planned work into day-of operational tasks. Harry Leak: 'We need to get to this really — centralising the work packages and then being able to drop them on the team's calendar, drag and drop, from a triage list.'

yes it it should be strictly a day view with flick beyween

what is your recommendation

**Patient zone assignment model:** When a patient is enrolled on a waitlist or initiates self-booking, the zone constraint must resolve their eligible zone(s). It is not yet defined whether a patient holds a single zone assignment, a zone-group assignment, or whether zone eligibility is derived dynamically (e.g. from their registered practitioner's zone). The data model for patient zone assignment and how it interacts with the accessibility needs filter (4.5) needs to be defined before the waitlist broadcast logic (7.6) can be fully implemented.

**Zone constraint enforcement for patient-initiated booking (Authoritative)**

For patient self-booking (mobile app) and Digital Waitlist offer matching, the zone constraint is a hard gate: patients MUST only be offered slots within their assigned zone or zone group. Patients MUST NOT be able to book into any available slot across the full diary.

The zone constraint is resolved at search time using the patient's zone assignment and the zone configuration held in Appointment Manager. Where no zone assignment exists for a patient, the default zone policy (as configured at practice level) applies.

This constraint operates in addition to the accessibility needs filter (4.5) and all other constraints in the availability search model.

### 3.5 DiaryNote (Canonical Artefact)

A DiaryNote is a governed digital artefact representing a staff-authored note displayed in the Huddle Box at the top of the Day View diary for a specific practice date.

Minimum required fields:

- `DiaryNoteId` — unique identifier
- `PracticeDate` — the calendar date to which the note belongs (ISO date)
- `Body` — free-text note content
- `LinkedAppointmentId` — optional FK to an `Appointment` record on the same `PracticeDate`; nullable
- `CreatedBy` — user identity
- `CreatedAt` — UTC timestamp
- `AuditTrail` — immutable append-only log

Rules:

- A DiaryNote MUST belong to exactly one `PracticeDate`.
- `LinkedAppointmentId` is optional; a note without a linked appointment is a valid, standalone note.
- Where `LinkedAppointmentId` is set, the referenced appointment MUST exist on the same `PracticeDate`; cross-date linking is not permitted.
- DiaryNotes are scoped to the practice (or site in multi-site deployments); they are not patient records and MUST NOT appear in patient audit trails.
- DiaryNotes are subject to RBAC: minimum role required to create or delete a DiaryNote is Reception; read access is granted to all authenticated staff roles with diary access.
- All create and delete events are audit-logged with actor and timestamp.

**Huddle Box (Diary Day View — top panel)**

The Huddle Box is a persistent panel fixed at the top of the Day View diary screen. It is designed to replace the practice of placing informal sticky-note annotations directly on the diary column (a pattern observed in tools such as Dentally), which is messy and inconsistent with the governed diary model.

Behaviour:

- Staff may add freeform notes to the Huddle Box at any time during the day. Notes do not require a linked appointment.
- A note MAY be optionally linked to a specific appointment on that day's diary. Linking is optional.
- When a user clicks a note that has a linked appointment, the diary scrolls to and visually highlights the linked appointment (a 'flash' or emphasis treatment).
- The Huddle Box acts as the practice's daily checklist and focus list — a structured home for things the team needs to remember on that day (e.g. "Patient X needs ground-floor surgery", "Nurse Y is off today").
- Notes are scoped to the practice day and are not carried forward automatically.

The Huddle Box is intended to support the morning 'huddle' workflow where the practice team reviews priorities for the day before sessions begin.

*(Exact panel heading, note-entry placeholder copy, link-appointment control label, and highlight animation treatment need UX writer and design system input.)*

Yes this should be inlcuded in the design and optional in aftercare templates if chosen

? The team discussed whether the aftercare template builder should have a bespoke drag-and-drop layout design or whether it can reuse existing block/component library elements from the forms surface. Harry confirmed templates should be clonable and editable, but the design approach (full drag-and-drop builder vs component reuse) was not formally resolved. Needs confirmation before Elvina begins detailed aftercare template design.

- **PMS API — charted treatment data per appointment:** Can the PMS API (e.g. Dentally) return the tooth number(s) and treatment surface information from the charted treatment plan item that is linked to a specific diary appointment? This is the preferred source for `ToothNumbers[]` on the `AppointmentDayRow`. If unavailable via the API, the fallback is appointment-level notes, which are less reliable. Engineering must confirm whether this data is exposed before finalising the data model for tooth-number display on the decon and surgery tablets. Raised by Harry Leak during decon tablet requirements discussion.

## Form Template Library (Authoritative)

The forms module MUST ship with a pre-populated library of form templates so that practices can begin using forms immediately without building them from scratch.

### Seed Templates

- The initial template library is seeded from Foxbury's existing form documents, covering the standard forms required for dental practice operations.
- Seed templates are provided by the platform operator at deployment time.
- Each seed template contains pre-authored content (all required sections and wording) and is ready to use out-of-the-box.

### Branding Inheritance

- Templates MUST automatically inherit the practice's top-level branding configuration (logo and font) from the platform branding settings.
- No per-template branding configuration is required; branding is applied at render/export time.
- The rendered form must visually identify as coming from the practice.

### Clone and Edit

- Practices MAY clone any template to create a practice-specific version.
- Cloned templates are fully editable via the drag-and-drop form builder.
- The original seed template remains unchanged and available to all practices.
- Practices MAY also create entirely new forms from scratch using the drag-and-drop builder.

### Template Import (Post-MVP Investigation)

- A capability to upload an existing document (e.g. a Word file) and have the system parse and auto-generate a draft form for review, tweaking, and saving is a desirable future feature.
- This feature requires a detailed specification before implementation and is not committed to MVP.
- John confirmed feasibility is possible with a detailed spec; Harry confirmed intent.