4.8 Notifications & Help Requests

4.8.1 What's New

4.8.2 Notifications Inbox

What the user sees

A dedicated page (Notifications) reachable from a button on the side rail; the button shows an unread counter.

Each notification row contains:

• Type badge (System Notification, Inquiry Update, Handover, Important Notification, Holiday, Sickness, Emergency).
• Title (e.g. "Your inquiry has been accepted by a consultant.").
• Body (e.g. "Your recent request for the consultation has been accepted, now you can chat with the consultant.").
• Date in MM/DD/YYYY format.
• Reply button (opens the relevant chat).
• View Chats CTA at the top of the inbox.

Source of notifications

Channels

• In-app (always).
• Email (only if the client provided one — never visible to counselors).
• Push (planned via Matrix Push Gateway — see Figma analysis §4.7).

Persistence & retention

• Notifications are per-user.
• Unread → 90 days, then archived.
• Archived → 12 months, then purged.
• A client's notifications are wiped together with the client on disconnect / account deletion.

4.8.3 Help Requests / Internal Escalation

Triggered from Chatraum Einstellungen → Hilfe Anfragen (⇧Ä) with the copy:

"Eskaliere den Fall intern oder extern ohne den Datenschutz zu vernachlässigen." "Wähle intern von einer Person ohne den Datenschutz zu vernachlässigen."

Flow

sequenceDiagram
  autonumber
  participant Co as Counselor
  participant FE as ORISO-Admin
  participant US as UserService
  participant Sup as Supervisor / Peer counselor

  Co->>FE: Click Hilfe Anfragen (⇧Ä)
  FE->>Co: Modal: pick mode (Intern / Extern), pick recipient
  Co->>FE: Submit
  FE->>US: POST /escalation { sessionId, recipient, mode, note }
  US->>Sup: Notification + read-only Matrix invite
  Sup-->>FE: Open chat, review, reply (in-thread or new note)
  FE->>US: POST /escalation/{id}/resolve

Modes

Privacy guarantees

• The recipient gets the same E2EE protection as a regular member.
• For external escalation, only opaque metadata + a contact-back token is sent.
• The audit log records the escalation event but never message bodies.

4.8.4 System Messages In-Chat

A typed taxonomy of system-generated banners that can appear inside a chat:

System messages render with a distinctive style (centered, neutral colour) to distinguish them from human messages.

4.8.5 Carimat — Scripted Bot

Carimat is the platform's planned rule-based onboarding bot. It is not an LLM. Behaviour:

• Posts the first system messages (E2EE banner, GDPR text).
• Optionally walks new clients through a multi-turn quick guide.
• Listens for explicit commands like /help, /topic, /language.
• Cannot read replies — it only posts pre-scripted content based on triggers.

Status: [NEW FEATURE] — name confirmed in Figma; behaviour proposed.

4.8.6 Permissions & Settings

Per-chat-type controls (see Roles & Permissions §3.7):

• Notifications can be muted per chat (Stummschalten ⇧Ö).
• A tenant admin can disable Help-Requests for a chat type entirely.
• Email mirror is opt-in at the user level + permitted at the tenant level.

4.8.7 Edge Cases

• User with no email opts in to email mirror → UI explains the opt-in is unavailable until an email is added.
• Notification arrives for a wiped pseudonym → notification is dropped silently; sender does not get a delivery error.
• Help Request to a counselor on holiday → falls back to the next-up Supervisor in the agency.
• External escalation timeout → cancel after 24 h; counselor is informed; nothing leaves the system.

4.8.8 Related

• Group Chats — Help Requests live in chat-room settings.
• Handover — pairs with system messages and notifications.
• Roles & Permissions.
• Figma Analysis.