Hearpeers Community — Notifications Overview

1 The two notification systems

Hearpeers currently runs two parallel notification systems. They are independent — an event can trigger one without the other.

System	What it does	Where users see it
In-platform notifications	Alerts that appear inside the platform	Bell icon (top navigation) + notification count badge
Email notifications	Emails sent to the user's inbox	User's email address

User control: Users can control their email notification preferences in Account Settings. In-platform notifications cannot currently be turned off individually.

2 Notification triggers — what exists today

Social actions

What happens	Who gets notified	In-platform bell	Email sent
Someone likes your post	Post author	Yes	No
Someone comments on your post	Post author	Yes	Yes
Someone replies to a comment	Comment author	Yes	Yes
You @mention someone in a post or comment	Mentioned user	Yes	Yes
You save a post	No one	No	No

Connection actions

What happens	Who gets notified	In-platform bell	Email sent
You receive a connection request	Recipient	Yes	Yes
Your connection request is accepted	Requester	Yes	Yes
Your connection request is rejected	No one	No	No
You cancel a connection request	No one	No	No

Group actions

What happens	Who gets notified	In-platform bell	Email sent
You are invited to a group	Invited user	Yes	Yes
Someone requests to join your group	Group admin	Yes	Yes
Your membership request is approved or rejected	Requester	Yes	Yes
Group details are updated	All group members	Yes	Yes
A backend admin adds a user to a group	All group members ⚠️	Yes	No
You are promoted to group admin	Promoted user	Yes	Yes

⚠️ Known issue: When an admin adds a user to a group via the backend (not through the community interface), all existing group members receive a bell notification — not just the newly added user. This creates unnecessary noise. See Section 5 for the proposed fix.

Direct messages

What happens	Who gets notified	In-platform bell	Email sent
You receive a direct message	Recipient	Yes	Yes

System / account emails

These emails are transactional — they are always sent and cannot be turned off by users.

What happens	Who receives it	Email sent
Account created	New user	Yes (welcome email)
Invitation to join the platform	Invited user	Yes
Password reset requested	User	Yes
Password reset completed	User	Yes
Profile verification	User	Yes

Note: These emails live in a separate code path from the notification system. They are not controlled by the notification preferences in Account Settings.

3 Notifications, the feed, and the daily digest

The activity feed

The activity feed (home page) is separate from notifications. It shows a stream of community activity — posts, joins, profile updates — but does not generate notifications. Users discover this content by visiting the feed; nothing is pushed to them for feed activity.

How they relate

What triggers it	Feed	Bell	Email
Post or comment by someone you follow	Yes	No	No
Someone likes your post	No	Yes	No
Someone comments on your post	No	Yes	Yes
Group update	No	Yes	Yes
New direct message	No	Yes	Yes
New connection request	No	Yes	Yes

The daily digest not yet built

The daily digest is a proposed feature (FR-24) — a single daily email summarizing all low-urgency notifications from the past 24 hours, sent at 08:00. It does not exist in production today. Details in Section 6.

4 What is in production vs. what is pending

Currently live in production live

In-platform bell notifications for: group updates, membership requests, connection requests, post likes, comments, @mentions, direct messages
Email notifications for: comments, @mentions, DMs, connection requests and acceptances, group invites, group membership status, group admin promotions, group updates
System emails: welcome, invitation, password reset, verification
Notification preferences in Account Settings (10 toggles)

Known issues in production issues

Issue	Impact	Priority
Notification badge shows "100" instead of the real unread count	Users cannot tell how many notifications they actually have	High
"Mark all as read" button does not work — count does not reset	Badge stays at 100 even after visiting notifications	High
Backend admin adding a user to a group notifies all members, not just the new user	Notification noise for all group members	Medium
Post likes generate a bell notification but no email (no preference toggle available)	Consistent — likely intentional, but not formally confirmed	Low

Not yet built pending

Daily digest (FR-24)
Individual notification preferences per notification type (FR-16) — currently users can only turn email on/off per category, not per notification type
Timezone-aware digest delivery — user timezone is not currently stored; digest would send at fixed server time (08:00)

5 Email types and translations inventory

All email types currently in the system

Email type	When it is sent	Trigger	Category
Welcome / account created	Immediately on registration	User registers	Transactional
Platform invitation	Immediately on invite	Admin or user invites someone	Transactional
Password reset	Immediately on request	User requests password reset	Transactional
Password reset confirmed	Immediately on completion	User completes reset	Transactional
Profile verification	On verification event	Verification triggered	Transactional
New comment on your post	On event	Second user comments	Notification
Reply to your comment	On event	Reply submitted	Notification
@mention in post or comment	On event	User @-mentions	Notification
New direct message	On event	DM sent	Notification
New connection request	On event	Request sent	Notification
Connection request accepted	On event	Request accepted	Notification
Group invite	On event	Invite sent	Notification
Group membership request (to admin)	On event	User requests to join	Notification
Membership request approved/rejected	On event	Admin acts on request	Notification
Group details updated	On event	Admin updates group	Notification
Promoted to group admin	On event	User promoted	Notification

Translations inventory updated

Architecture confirmed from code — string content requires database export to verify.

The platform supports three languages: English (en-US), German (de-DE), and Spanish (es-ES).

Email translations use two separate systems: custom plugin emails pull translated strings from the WordPress database at send time, keyed to the recipient's locale. Actual string content is stored in WordPress ACF custom fields and is not visible in the PHP code — verifying content requires a WP admin export or direct DB query. BuddyPress core emails use the standard WordPress/BP i18n system and depend on language packs installed on the server. Two emails are English-only with hardcoded subjects and no locale lookup: community invitation and new question post notification.

Email type	Languages	Translation system	Notes
Welcome / account created	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Password reset / 2FA code	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Password changed	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Account deleted	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Group welcome (on join)	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
New comment on your post	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
@mention in comment	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
New direct message	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
New connection request	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Connection request accepted	EN, DE, ES	Custom plugin (DB)	Fully wired; strings in ACF
Area assignment change (to manager)	EN, DE, ES	WP gettext	Depends on WP language packs installed on server
Group membership request (to admin)	EN, DE, ES	BuddyPress core	Depends on BP language packs installed on server
Membership request approved/rejected	EN, DE, ES	BuddyPress core	Depends on BP language packs installed on server
Group invite	EN, DE, ES	BuddyPress core	Depends on BP language packs installed on server
Promoted to group admin	EN, DE, ES	BuddyPress core	Depends on BP language packs installed on server
Community invitation	EN only	Hardcoded	Subject hardcoded in English; no locale lookup
New question post (to mentors)	EN only	Hardcoded	Subject hardcoded in English; no locale lookup

To verify the actual translated content (EN/DE/ES strings): export the ACF translation fields from the WordPress admin panel, or query the postmeta table for keys prefixed translation_value_. This cannot be done from code alone.

6 Proposed strategy

The following section presents our recommendation for how notifications should work going forward. This is a proposal for discussion — nothing here is final until agreed with MED-EL.

The problem with the current approach

Today, the platform treats all notifications the same. Any event that can send an email does so immediately, and users cannot distinguish urgent from non-urgent. This leads to two failure modes:

Volume fatigue: Area Managers and Mentors receive frequent emails for low-urgency group updates and end up disabling all notifications — missing connection requests from Candidates.
Missing granularity: Users who want fewer emails have only one option: turn off entire categories (e.g., "all group emails"), rather than reducing frequency.

Proposed: two-track delivery model

We propose organizing all notifications into two tracks based on urgency.

Instant

Events that require prompt attention — where a delay would break the user's workflow or leave someone waiting.

Event	Who receives it	Rationale
New direct message	Recipient	Personal and time-sensitive
New connection request	Mentor / Area Manager recipients	A Candidate is waiting for support
First comment on your post	Post author	Primary social feedback signal
@mention in post or comment	Mentioned user	Direct address — requires response
Promoted to group admin Mentor / Area Manager only	Promoted user	Role change — should be immediate. Candidates and Recipients are never promoted to group admin.

Daily digest

Events that are informational or low-urgency — where batching reduces noise without missing anything important.

Event	Who receives it	Rationale
Connection request (Candidate recipient)	Recipient	Lower volume; no immediate action needed
Connection request accepted	Requester	Confirmatory; no action required
Group membership request (to admin)	Group admin	Admin task; daily cadence is sufficient
Membership request approved/rejected	Requester	Confirmatory
Group invite	Invited user	Discovery; not time-sensitive
Group details updated	Group members	Informational; currently high volume
Subsequent comments on a post (2nd and beyond)	Post author	Batched as "N people commented on your post"

Bell only

Not sent by email — in-platform notifications only.

Event	Rationale
Post likes	High volume, low urgency
Profile updates by others	Activity feed is sufficient
Group joins/creates by others	Activity feed is sufficient

Before and after, by role

The matrix below shows every notification event and how its delivery changes for each role. Today, there is no digest — everything that sends an email does so instantly. The proposed model introduces the digest track and redirects low-urgency events into it.

Candidate Candidate / Caregiver

Self-registered user — newly diagnosed, candidate for implant, or caregiver. Low-volume user profile.

Event	Today	Proposed	Change?
New direct message	Instant	Instant	No change
@mention in post or comment	Instant	Instant	No change
First comment on your post	Instant	Instant	No change
Subsequent comments on your post	Instant (each)	Digest (batched)	Reduced
Connection request received	Instant	Digest	Reduced
Connection request accepted	Instant	Digest	Reduced
Group invite	Instant	Digest	Reduced
Group details updated	Instant	Digest	Reduced
Membership request approved/rejected	Instant	Digest	Reduced
Post like received	Bell only	Bell only	No change
Welcome / system emails	Instant	Instant	No change

Candidates are low-volume users. The main gain is tidying up group noise and batching secondary comments.

Recipient Recipient

Confirmed cochlear implant recipient. Moderate volume user.

Event	Today	Proposed	Change?
New direct message	Instant	Instant	No change
@mention in post or comment	Instant	Instant	No change
First comment on your post	Instant	Instant	No change
Subsequent comments on your post	Instant (each)	Digest (batched)	Reduced
Connection request received	Instant	Digest	Reduced
Connection request accepted	Instant	Digest	Reduced
Group invite	Instant	Digest	Reduced
Group details updated	Instant	Digest	Reduced
Membership request approved/rejected	Instant	Digest	Reduced
Post like received	Bell only	Bell only	No change
Welcome / system emails	Instant	Instant	No change

Similar to Candidates. Moderate volume; the digest reduces email frequency without losing anything urgent.

Mentor Mentor

Trained volunteer mentor. High-volume user with group responsibilities.

Event	Today	Proposed	Change?
New direct message	Instant	Instant	No change
@mention in post or comment	Instant	Instant	No change
First comment on your post	Instant	Instant	No change
Subsequent comments on your post	Instant (each)	Digest (batched)	Reduced
Connection request from a Candidate	Instant	Instant	Preserved ★
Connection request from a Recipient	Instant	Digest	Reduced
Connection request accepted	Instant	Digest	Reduced
Group invite	Instant	Digest	Reduced
Group details updated	Instant	Digest	Reduced
Membership request approved/rejected	Instant	Digest	Reduced
Post like received	Bell only	Bell only	No change
Welcome / system emails	Instant	Instant	No change

This is where the most value is. Mentors currently receive instant emails for every group update — high volume that leads them to disable notifications entirely. The proposed model keeps the one event that matters most (a Candidate reaching out) instant, and moves everything else to the digest. Mentors stay reachable without being overwhelmed.

Area Manager Area Manager

Regional manager — oversees users and groups within an area. Highest individual notification volume.

Event	Today	Proposed	Change?
New direct message	Instant	Instant	No change
@mention in post or comment	Instant	Instant	No change
First comment on your post	Instant	Instant	No change
Subsequent comments on your post	Instant (each)	Digest (batched)	Reduced
Connection request received	Instant	Digest	Reduced
Connection request accepted	Instant	Digest	Reduced
Group membership request (admin action required)	Instant	Digest	Reduced
Membership request approved/rejected	Instant	Digest	Reduced
Group invite	Instant	Digest	Reduced
Group details updated	Instant	Digest	Reduced
Promoted to group admin	Instant	Instant	No change
Post like received	Bell only	Bell only	No change
Welcome / system emails	Instant	Instant	No change

Highest volume role. Area Managers manage multiple groups and currently receive an instant email for every group update across all of them. The digest consolidates all group activity into one daily summary — the single biggest noise reduction in the whole proposal.

Super Admin Super Admin / MED-EL Backend Users

Highest-privilege community governance role. Not currently differentiated in the notification system.

Event	Today	Proposed	Change?
All notification events	Same as other roles	To be defined by MED-EL	To be agreed

Super Admins are not currently differentiated from other roles in the notification system. We recommend MED-EL define their notification needs separately — they may want no email notifications at all, or a different digest cadence.

What needs to be built

Item	What it is	Status
Fix notification badge (real count, reset on visit)	Frontend fix	Not built
Fix "mark all as read"	Frontend + backend fix	Not built
Fix backend group additions (notify added user only)	Backend fix	Not built
Daily digest queue	Backend — new queue for batched events	Not built
Daily digest cron job	Backend — daily sweep, sends one email per user	Not built
Daily digest email template	Email — one summary template with conditional sections	Not built
Digest preference toggle in Account Settings	Frontend + backend	Not built

One open research question

Why did you turn off email notifications?

This question confirms whether frequency is the problem (in which case the digest solves it) or whether the issue is content irrelevance or platform distrust (which require different solutions). This research should run before development begins on FR-24.