Anatomy
┌─ Notifications ───────────────────────── 3 unread ─┐
│ ● Priya mentioned you on INV-1043 2h ago │ ← act
│ "can you check the labour hours before we send?" │
│ ● JOB-204 was handed to you by Sales yesterday │ ← act
│ ● 4 comments on JOB-118 yesterday │ ← grouped, not 4 rows
│ Dana, Sam and 1 other │
└────────────────────────────────────────────────────┘
each row links to the RECORD, not to a list
The three rules that decide whether this works:
- Only actionable events. The test is whether a reasonable person would do something. If not, it is timeline material.
- Grouped. One record's burst of activity is one row.
- Deep links. A notification that drops you on a dashboard has made you do the finding it was supposed to save you.
Why it works
It works only through restraint, which is why this entry is mostly about what NOT to send. The engineering is easy and the judgment is hard. Every stakeholder wants their event notified, each request is individually reasonable, and the cumulative result is a channel nobody reads.
The failure is not gradual — it is a cliff. Up to some volume, people read notifications. Past it, they mute or bulk-archive, and from that moment the channel carries nothing, including the important messages. You cannot recover by adding a priority flag later, because nobody is looking.
So the useful discipline is a budget, like the one on a glance layer: to add a notification type, justify it against the ones that exist, and be willing to remove one.
Urgency is a separate axis from delivery
Two questions, often conflated:
| Question | Answer shapes |
|---|---|
| Does someone need to act? | Notify, or put it in the timeline |
| Can it wait until they next open the app? | In-app only, or email/SMS too |
Most events that deserve a notification do not deserve an email. Getting this wrong is how a product ends up in a mail filter, at which point the in-app notification is fine and nobody sees the email that mattered.
Getting it wrong
- Notifying people about their own actions, the fastest way to train everyone to ignore the icon.
- One per event during a bulk operation — forty emails from one click.
- A count that does not clear when you read the underlying record.
- Links to a list, not the record.
- No per-category preferences, so the only available control is "all off".
- Everything by email, which puts the product in a filter permanently.
Exemplars
GitHub's notification model is unusually explicit about the distinction: participating versus watching, and per-repository settings. The lesson is that the reason you got a notification is itself information, and showing it lets people tune rather than mute.
Linear groups aggressively and defaults to in-app, with email reserved for things assigned to you. The result is a notification list people actually read.
Slack's @-here versus @-channel is the clearest demonstration of the cliff: the moment a workspace normalises broad mentions, everyone mutes the channel and the mechanism is dead for everyone.
The extractable rule: notifications are a budget, not a feature. Every one you add spends attention that the important ones need, and the failure mode is sudden and permanent.