Enabling Push Notifications
Push notifications reach somebody when they are not looking at the application — the server tells the device rather than the device asking.
Where to find it
Architect Panel → Background Messaging:
- Push Notifications — the configuration and subscriptions
Architect Panel → Mobile Apps:
- Mobile Canvas — the app delivery path
Push against polling
Polling suits steady refreshing of something on screen. Push suits discrete events — something happened and somebody should know.
Push also reaches people who do not have the application open, which polling cannot do at all. That is the substantive difference and the reason to use it.
It needs the user’s permission
The browser asks, not you, and the answer is often permanent. A refusal is difficult to reverse — the user must go into browser settings, which effectively nobody does.
So you get roughly one chance per user.
When you ask is the whole game
The mistake is asking on arrival, before the person knows what your application is. Faced with an unexplained permission prompt from an unfamiliar site, most people decline — and that decline is close to permanent.
Ask at a moment when the value is obvious: just after somebody submits a request they will want an answer to, or when they explicitly choose to be notified about something. Explain what they will receive first, in your own interface, and only then trigger the browser prompt.
Organisations that get this right see acceptance rates several times higher than those that ask on the home page.
Let people opt in deliberately
Better than a prompt at all is a visible control — "notify me when this changes" — that the user chooses to switch on. Then the browser prompt arrives as a consequence of something they asked for.
What is stored
A subscription per user and device: the endpoint the device is reachable at, the subscription details, and what agent it came from. One person with a laptop and a phone has two.
Subscriptions go stale
Devices are replaced, browsers are cleared, permissions are revoked. Expect a proportion of subscriptions to stop working, and treat repeated delivery failures as a signal to remove one rather than something to retry forever.
Do not make it the only route
Push is best-effort. It depends on permission, a working subscription, a device being reachable and the user's own notification settings. Anything that genuinely must reach somebody needs e-mail or another channel behind it.
Worked example
A service asks for notification permission only after somebody submits a request, with a line explaining they will be told when it is answered. Acceptance is around 60%. Every notification is also sent by e-mail, so nobody misses an outcome because a subscription had lapsed.
Recommendations
- Never ask on arrival — you get one chance.
- Explain first, in your own interface.
- Prefer an explicit opt-in control.
- Keep another channel behind anything important.