The platform fires a small set of in-app notifications on specific events. Each notification has a trigger type that determines when it fires, who receives it, and what the body says.
The seven triggers
In v0.5:
| Trigger | Fires when | Recipients |
|---|---|---|
ONBOARDING | A user accepts an invitation | The user themselves |
ASSESSMENT_ASSIGNED | An assessment is assigned | The assignee |
REPORT_READY | An assessment narrative completes generating | The assessee |
PLAN_EDITED | A growth plan is edited | The plan's other two parties (not the editor) · Special case: when an employee changes their own target role, the notification goes to the line manager and HR admins only (not back to the employee). |
CANDIDATE_APPLIED | A new application lands in a hiring pipeline | HR admins + line manager assigned to the role |
CV_SCREENED | A CV screening completes | HR admins + line manager assigned to the role |
CANDIDATE_HIRED | A hire handoff completes | HR admins + line manager assigned to the role |
What is in a notification
Each record holds:
- Type (one of the seven).
- Title — a short headline.
- Body — a sentence or two of detail.
- Link — the URL the platform takes you to when you click.
- Read flag — false on creation; true once you have read it.
- Created timestamp.
Notifications appear in the bell at the top of the page; the full archive is at /{slug}/app/notifications (HR view) or /{slug}/me/notifications (employee view).
Batching
Some triggers — notably PLAN_EDITED — are batched. Bursts of plan edits from the same actor within a ten-minute window produce one notification rather than ten. The window is short enough that you still see edits within the day; long enough to absorb editing bursts.
Batching is type-specific. ASSESSMENT_ASSIGNED and CANDIDATE_APPLIED are not batched — each event produces its own notification.
What does not trigger
To pre-empt assumptions, the platform does NOT notify on:
- Profile views. No one is alerted when their profile is read.
- Competency profile updates that did not change a user-visible value.
- Workspace settings changes.
- Other administrators' invitations or removals.
- Routine background processing (cache invalidation, profile recomputation).
Volume is deliberately low. The bell is meant to be useful, not noisy.
How notifications are delivered
In v0.5: in-app only. The bell shows the count; clicking opens the dropdown; the dropdown is the channel.
Email notifications are on the v0.6 watch list. The most-requested email channel is for ASSESSMENT_ASSIGNED (especially with a deadline) — many workspaces want it.
Push notifications (mobile) are not in v0.5 and are not on the immediate roadmap.
Per-user preferences
Not in v0.5. Every user receives every notification their role triggers. Per-user opt-out (e.g., an HR admin who does not want CV_SCREENED notifications because they have set the auto-advance threshold high) is on the v0.6 watch list.
Polling and real-time
The bell polls for new notifications every 60 seconds when the page is open. There is no WebSocket-based real-time push in v0.5; you may see a brief lag between an event and the bell badge updating.
If you have just performed an action and expect the resulting notification immediately, refresh the bell dropdown — the platform fetches the latest list on dropdown open.