Staff ↔ player messaging

TL;DR

Bidirectional internal messaging between staff and player, with one thread per player. Staff write from the player’s profile; the player writes from their portal. Each staff message automatically fires a push notification to the player’s phone. The unread badge on the staff side counts pending incoming messages.

For sales

• Problem it solves: today staff and players communicate via WhatsApp / SMS, with no traceability, mixed with private life, and no org control over the channel. CÉNIT centralizes that thread inside the app, with native push notifications, and leaves the history auditable.
• Typical use cases:
  • Notify the player about a schedule change or medical appointment.
  • Player reports pain to the S&C without making a phone call.
  • HoP responds to a player’s question about planning.
• Plans that include it: all plans.
• Differentiator: native PWA + web push integration (no app store required), all inside the multi-tenant system with per-org isolation — a staff member from Org A cannot send messages to players in Org B (validated on the server).

How staff use it

Access and permissions

• Who can see threads: every staff member with access to the player’s profile (depends on the org’s visible-tabs configuration and the role). In practice HoP and Sporting Director have guaranteed access; physio, physician, nutri, and psi have it if the tab is enabled.
• Who receives messages from the player: if the player sends without an explicit recipient, the system assigns it to the org’s first HoP or Sporting Director.
• Cross-tenant security: the server validates that the target player belongs to the caller’s org on every send.

Step-by-step flows

Staff side:

1. Open the player’s profile → Messages tab.
2. See the thread with messages ordered, unread badge above counting pending messages from the player.
3. Type and send.
4. Automatically: the system fires a push notification to the player. Fails silently if the player isn’t subscribed to push.

Player side:

1. Push notification arrives on the phone (if the PWA is installed and the subscription is active).
2. Tap opens the messages screen in the player portal.
3. The player replies — the message is assigned to the first HoP or Sporting Director.

Related configuration

• Push notifications require the CÉNIT client to have VAPID keys configured for web push.
• Player push subscription: enabled from the player portal with the “Activate notifications” button.

FAQ / edge cases

• “The player doesn’t receive the push” — check that: 1) the PWA is installed, 2) notification permission was granted, 3) “Activate notifications” was tapped in their portal.
• “Endpoint expired” — if the player’s browser invalidated the subscription, the system cleans the endpoint automatically.
• “Empty message rejected” — content cannot be empty or exceed 2000 characters.
• “Message crossed between orgs” — blocked on the server: if the target player doesn’t belong to the caller’s org, the send is rejected.
• “Read-only impersonation doesn’t send” — during a superadmin impersonation in read-only mode, sends are blocked.

How the player sees it

Player surface: YES. It is one of the few modules with a player surface.

• Screen: simple thread in the player portal, text input, history scroll.
• Push notifications: automatic on every staff message. Title: “Message from [staff name]”. Body: first 80 characters of the message.
• Badge: the player portal can show an unread badge.
• No email: messaging doesn’t send email; only push + in-app.

Integrations

• PWA / Service Worker — the service worker handles the push event and shows the native notification.
• Squad — the Messages tab renders from the player’s profile.
• Impersonation — sends are blocked during read-only impersonation.

Limitations

• No attachments — plain text up to 2000 characters only.
• No group / broadcast — you can’t send the same message to N players in a single send.
• Auto-assignment to HoP / Sporting Director: when the player writes, the recipient is the first HoP or Sporting Director found. There is no UI for the player to choose the recipient.
• No “read by staff” — the system marks read on the staff side when staff read the player’s messages. The reverse (player read staff message) is not implemented.
• No retention or archival — threads grow without limit.