Web Push Notifications
The push engine lets the site send notifications to a user’s device, even when they do not have it open.
Where to find it
Architect Panel → Background Messaging:
- Push Notifications — the VAPID keys web push needs
Architect Panel → Configuration:
- Site Settings — the Progressive Web App and Service Workers option groups
What it needs
Web push is signed with a key pair — a public key given to browsers and a private key held by the server. The Push Notifications setup screen shows whether both are present and can generate them if they are not.
Generation is a one-time act. Once keys exist and browsers have subscribed against the public key, replacing them invalidates every existing subscription.
Do not regenerate keys casually
The setup screen refuses to overwrite keys that are already configured, which is the right behaviour. Regenerating means every subscriber silently stops receiving notifications, and there is no message telling anybody.
The user has to agree
Browsers require permission, asked once. If somebody declines, you cannot ask again in any useful way — the browser remembers, and re-enabling means the user going into their own settings.
So the one prompt you get is worth spending.
Ask at the right moment
Not on arrival. Somebody who has just done something that would benefit from a notification — booked an appointment, raised a request, subscribed to an update — understands what they are agreeing to.
Explain what you will send before the browser prompt appears, so the prompt confirms a decision rather than posing a question.
Send few, and send useful
A notification interrupts somebody. The threshold should be "would they want to be interrupted for this", which is a much higher bar than "is this a thing that happened".
Organisations that send everything end up with users who have disabled everything.
The message is short
A title and a line of text. Say what happened and what it concerns; there is no room for anything else, and the notification is a prompt to open the app rather than a substitute for it.
Do not put anything private in it
Notifications appear on locked screens, visible to whoever is holding the phone. A name, a case reference or a medical detail in a notification is that information shown to a stranger on a train.
It is not reliable delivery
Push is best effort. Devices are off, subscriptions expire, browsers drop them. Anything that must reach somebody needs e-mail or another channel as well.
Worked example
A service asks for push permission immediately after a user books an appointment, having explained that it is used for reminders and changes only. Notifications say "Your appointment has moved" without naming the service. Roughly two thirds accept, and unsubscription is negligible.
Recommendations
- Generate keys once and never casually replace them.
- Ask after a relevant action, having explained first.
- Nothing private in the text — it shows on lock screens.
- Pair with e-mail for anything that must arrive.