Push Notifications

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.

Delivery Paths

Notifications reach people two ways, and an installation may use both.

Where to find it

Architect Panel → Background Messaging:

• Push Notifications — web push subscriptions

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, and its push delivery settings

Web push

Through the browser, using a service worker and a subscription tied to that browser on that device. It works without an app, on desktop and mobile, and it requires no app store.

The subscription belongs to the browser, so somebody using two browsers has two — and clearing site data removes it.

Mobile app push

Through the platform's mobile app, delivered by the operating system's own service — Apple's for iOS and Google's for Android, each configurable.

More reliable than web push on mobile, and it requires the app to be installed.

One person, several subscriptions

Somebody with a work laptop, a phone browser and the app may hold three. That is correct — each is a device they might be looking at — and it means "notify this person" is not one delivery.

It also means a stale subscription among them causes a failure that is not a failure to reach the person.

Choosing

• Web push where users work at a desk, or where you cannot expect an app to be installed.
• App push where the audience is mobile and the app is already part of how they work.
• Both, where the population is mixed.

Reliability differs

App push is generally more dependable on a phone: mobile browsers are aggressive about background activity, and web push on iOS in particular has had a chequered history and requires the site to be added to the home screen in some versions.

If mobile reach genuinely matters, the app path is the stronger one.

Neither is guaranteed

Both depend on the device being reachable, the user's own notification settings, and a service you do not control. Treat delivery as likely rather than certain, and never as evidence somebody was told.

Test on real devices

Notification behaviour varies by operating system version, browser and the user's settings, in ways an emulator will not reveal. Test on actual phones — at minimum one recent iOS and one Android.

Worked example

An organisation uses web push for office staff and app push for field engineers, who already carry the app. Engineers hold both subscriptions and receive one notification per event because delivery is per person rather than per subscription. Critical alerts also go by SMS, since neither push path is guaranteed.

Recommendations

• Match the path to how people work.
• Prefer app push where mobile reach matters.
• Test on real devices, both platforms.
• Never treat delivery as proof somebody was told.

Service Workers and Delivery

Web push depends on a service worker — a small background component the browser registers for your site, able to receive a message when no page is open.

Where to find it

Architect Panel → Background Messaging:

• Push Notifications — subscriptions and their endpoints

Architect Panel → Configuration:

• Site Settings — the site address the registration is bound to

Why one is needed

Something has to receive the notification when the user is not on your site. A page cannot, because it does not exist at that moment. The service worker persists after the page has gone, which is the whole mechanism.

HTTPS is required

Service workers only register over a secure connection. That is not a platform choice — browsers enforce it — so push is unavailable on any site not served securely.

It is tied to your address

The registration and every subscription belong to the exact origin. Change your domain and every existing subscription is worthless — users must subscribe again, and there is no way to migrate them.

Worth knowing before a rebrand or a domain change, because the loss is silent: notifications simply stop arriving and nobody reports it.

Clearing site data removes it

A user who clears their browsing data unsubscribes without knowing. Their expectation is unchanged and notifications stop — which surfaces as "I stopped getting alerts" some weeks later.

Where notifications matter, having a visible indication of whether they are currently enabled saves that conversation.

Test what an arriving notification does

The click behaviour is the part most often left wrong. A notification that opens the home page when it was about a specific record wastes the moment you worked to earn.

Make it open the thing it is about, and check it when the application is closed, when it is open in the background, and when the user is already on the relevant page.

Check the appearance

Title, body and icon are what the user sees, often on a lock screen alongside a dozen others. A notification saying "Update" from an unrecognisable icon is deleted without being read.

Say what happened, specifically, and make the icon recognisably yours.

Do not notify too much

The fastest way to lose the channel. People turn notifications off at the operating system level, permanently, and you will never know they did.

Notify about things the person asked to hear about and things genuinely requiring action. Not every change.

Worked example

An installation checks notification behaviour on real devices after each release: clicking opens the relevant record rather than the home page, the icon is the organisation's, and the body names the case. Notifications are limited to assignment and outcome, which are the two things people said they wanted to know about.

Recommendations

• Serve the site over HTTPS — push requires it.
• Expect to lose subscriptions on a domain change.
• Make clicking open the right thing, and test all three states.
• Notify sparingly — over-notifying loses the channel permanently.