Notification explained: what it is, how it fires, and why volume decides whether it works
A notification is a message a system sends to tell a person or another system that an event has occurred, or that something now needs attention, delivered outside whatever screen the recipient is currently looking at. Email, SMS, push, an in app badge, or a webhook posted to another application are all notifications in this sense.
The hard design question is never whether the message is accurate. It is whether the recipient will still be reading messages of that kind in three weeks.
What does notification mean in a workflow system?
Inside an operations tool a notification is the push half of a pair. Status is available to anyone who looks. A notification decides not to wait for them to look.
That makes it expensive in a way the sending system never sees. Every notification spends a small amount of the recipient's attention, whether or not it turns out to have been worth reading, and that budget is shared across every system able to reach them.
How does a notification work?
- Event. The thing that happened. A submission arrived, an assignment changed, a deadline passed, a customer replied.
- Audience. Who actually needs to know. Usually far narrower than the list a default configuration produces.
- Channel. How it reaches them, chosen against urgency. In app for routine, email for the record, SMS or push for the genuinely time bound.
- Timing. Immediate, batched into a digest, or held until a working hour. Batching is the most underused control on this list.
- Payload. What the message says. A notification the recipient cannot act on without opening three other screens has only announced that work exists.
Why too many notifications are the same as none
This is the best documented failure in the whole subject, and the evidence comes from hospitals. The Joint Commission's Sentinel Event Alert issue 50, published on 8 April 2013, reported that alarm signals for a single patient can run to several hundred a day, and that an estimated 85 to 99 percent of alarm signals do not require clinical intervention.
What the alert describes next is what anyone designing notifications should expect. Clinicians became desensitised to the sounds and responded by turning the volume down, switching alarms off, or widening the thresholds. Between January 2009 and June 2012 the Joint Commission recorded 98 alarm related events, 80 of which resulted in a death.
An operations queue is not an intensive care unit. The failure mode is identical in shape. A team receiving forty notifications a day of which two matter does not get good at spotting the two. It stops reading all forty, and the ones that mattered fail quietly. Volume is not a neutral setting. It is the thing that decides whether the channel works at all.
Notification design explained: a retake request
A reviewer needs one photograph reshot. An email saying a case has been updated just moves the problem along: the recipient has to open the case to discover what changed, and half of them will not.
A message that names the case, states which step needs redoing and why, and links straight to that step turns the notification into the entire interaction. The same principle applies to a retake request sent to a customer, where a vague message reliably produces a second inadequate submission.
How notifications differ from reminders, alerts and status
- A reminder is scheduled against time rather than triggered by an event. Nothing happened. Something failed to happen, which is a different signal and often a more useful one.
- An alert implies a threshold and an expected response. Calling routine messages alerts is how the word stops meaning anything.
- An escalation is a notification aimed deliberately above the person who did not act. It only keeps working while it stays rare.
- Status tracking is the pull version of the same information, and it does not degrade with volume. Where a team already shares a queue view, much of what gets sent as notifications is better left sitting in the queue. See shared inbox.
Getting the volume right
- Notify the owner, not the team. A message to eight people is a message eight people assume somebody else is handling.
- Digest anything that is not time bound. One end of day summary beats fourteen separate updates, and it is far more likely to be read to the bottom.
- Put the required action in the message. A subject line naming the case and what is needed is most of the difference between a channel people trust and one they filter.
- Let people tune their own. Per event, per channel, at the level of the individual, because a workshop controller and a finance approver need different things from the same system.
- Audit what you send. Count the notifications generated per case per week. Most teams that count are surprised, and most of the rules producing the volume were added by workflow automation without anyone totalling them up.