Does Your Small Business App Need Push Notifications, Email or In App Alerts?

Short answer: if your workflow has a persistent status, such as a job, request or order moving through stages, a reliable in app status view is usually the first thing to specify, because it can show the current state to anyone who opens it. Add email when someone needs to learn about a change while they are away from the app. Add native or browser notifications only for the few events where a delay has a real cost, and only after you have decided what the app does when permission is refused. Each channel is a separate piece of scope, not a free extra.

This guide helps you decide which events interrupt people, through which channel, and what to write down before commissioning the work. Statements about platform behavior are cited next to the claim. Everything else is a practical recommendation from the author, offered as a starting position for your own project.

Step one: decide which events deserve to interrupt

Most events do not deserve an interruption. Three questions help.

1. Does a delay of an hour, or a day, change the outcome for the business or the customer?
2. Can the recipient act on it straight away?
3. Would they mind learning about it only when they next check the status view?

If the first two answers are no, the event belongs in the status view only. If they are yes, it is a candidate for email or a device notification. Business urgency decides this, not how easy an alert is to build.

Recommendation: write the event list first, label each event with an urgency (immediate, same day, whenever), and only then choose channels. Each event should have an owner who can say why it deserves its channel.

Three channels that are easy to confuse

In app status view or inbox. A screen inside the app that shows what is true now, and optionally a history of changes. It reaches only people who open the app, and where it requires sign in, only people who can sign in. It suits events that matter but do not need to interrupt anyone.

Email. It reaches people outside the app and keeps a copy in their own mailbox. How quickly it is noticed depends on the reader and their mail settings: one person sees it within minutes, another batches their inbox once a day. That uncertainty is the tradeoff, not an inherent weakness. Email suits detail that someone may want to keep, but it does not tell you the message was read.

Native or browser notification. A message shown by the device or browser outside the app. It depends on the person granting permission, on their device settings, and on the platform. It suits short, time sensitive prompts that point back to the full record.

Recommendation: when a status view exists, treat it as the source of truth. Email and device alerts should be generated from changes to that status and point back to it, rather than carry their own version of the facts.

Permission is not delivery, and not proof of reading

Three things get blurred together.

• Permission: the person allowed the site or app to show notifications.
• Delivery: a message actually reached a device or mailbox.
• Reading: the person saw it and understood it.

Permission is only the first. A granted permission does not prove a message arrived, and an arrived message does not prove it was read. Recommendation: do not build screens or reports that say "customer notified" when all you know is that a send was requested. Record the facts you actually have, such as "alert requested" or "status changed", and let the status view show the current state.

Browser notifications are not the same as a push subscription

This distinction changes the size of the job. Showing a notification from a page that is open is one thing. Receiving a message from your server while the page is closed is another, and it needs a push setup with a service worker, stored subscriptions and server side sending.

Documented: the Push API "gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent" (MDN, Push API). The same page says that "For an app to receive push messages, it has to have an active service worker" (MDN, Push API).

Practical reading: a short Notifications API example that displays a message is not a complete background push implementation. If you want alerts when nobody has the app open, say so in the brief and ask what the work covers.

Permission rules and what happens on denial

Documented for the web: "Before an app can send a notification, the user must grant the application the right to do so" (MDN, Using the Notifications API). MDN also advises that you "should only request consent to display notifications in response to a user gesture (e.g., clicking a button)", and that "In Chrome and Firefox you cannot request notifications at all unless the site is a secure context (i.e., HTTPS)" (MDN, Using the Notifications API). Browsers differ, so scope testing for the browsers your users actually use.

Documented for Android: Android 13 (API level 33) and higher has a runtime permission for sending notifications that are not exempt, and for a newly installed app on those versions, "your app's notifications are off by default" (Android Developers, Notification runtime permission). This guide limits the Android claim to that runtime permission and the newly installed default. It does not describe other versions or other platforms.

Recommendation: plan for a refusal from the start. If someone says no, the app should keep working and the status view should stay accurate. Offer a clear way to reconsider later, with a plain note on where the device or browser setting lives. Ask the permission question at a moment that makes sense, such as after the person chooses to follow a job, not on first load.

Email fallback is a decision, not a default. Do not assume email quietly replaces a refused device alert. If you want a fallback, write the rule: which events, which recipients, and who decided those recipients can be contacted that way. Do not assume customer consent from the fact that someone is a customer. Questions about legal duties belong with a qualified adviser, and this guide offers no legal advice.

Preferences versus device permission

There are two layers. The first is your app's own notification preferences or channel rules: which events a person wants and through which channel. The second is the device or browser permission, which your app cannot override. If the device permission is off, a preference switch inside the app cannot make alerts appear, and the screen should not imply otherwise. Show the honest state, for example "Device alerts are turned off in your settings", while the app preference stays visible.

Quiet hours and time zones as proposed scope

Quiet hours are not something to assume. Treat them as proposed scope and decide:

• Do they apply to staff, customers, or both?
• Whose time zone counts: the recipient's, the business's or the job location's?
• Which events, if any, may override them?
• When the quiet period ends, are held alerts sent one by one or as a single summary?

A smaller first version can leave quiet hours out and restrict device alerts to a short list of urgent events.

Lock screen text and the destination of a tap

Recommendation: assume the text of a notification can be seen by someone other than the account holder. Keep it minimal, for example "A job status changed", and leave names, addresses and details for the app itself.

A tap should open a safe, authenticated destination: the specific record, shown only after the person is signed in and allowed to see it. If sign in has expired, show the sign in step and then continue to the record. If the record has moved or no longer exists, show a clear message and a route to the status view. Keep sensitive details out of the link.

Stale and duplicate alerts

Alerts age quickly. A person may resolve the issue before they read the alert, or several changes may land within a minute. Decide what you want rather than assuming the platform handles it. Recommendation: define the status record as the source of truth, create alerts from changes to it, and require that opening an old alert always shows the current status, not the status at the time the alert was sent.

Hypothetical example: equipment repair job status

Imagine a made up small workshop that repairs equipment. Staff track each job, and customers can see progress. The matrix below is a proposal for discussion, not a standard.

Proposed rules: the status view updates first. Email follows only for the rows marked yes. A device alert reads "A job status changed" and opens the signed in job page. If the job has moved on by the time the alert is tapped, the page shows the current status. Nothing here implies a customer has agreed to any channel. That is a separate decision to record.

Proposed acceptance checks

These checks are proposals. Adapt them, and see how to write acceptance criteria for a small web app for turning them into testable wording.

• Each event in the matrix has an urgency label and a named channel list.
• Change a job status and confirm the status view shows the new state, with or without any alert.
• Deny the permission prompt and confirm the app still works and shows that device alerts are off.
• Confirm the permission prompt appears only after a deliberate user action.
• Turn off a preference and confirm the matching alert is not requested.
• Confirm no screen claims an alert was delivered or read unless that is actually known.
• Confirm any email fallback follows a written rule, or does not exist.
• If quiet hours are in scope, test held alerts across two time zones.
• Check that the lock screen text contains no personal or job details.
• Tap an alert while signed out, then signed in, then after the record has been removed, and confirm each result matches the specification.
• Open an old alert after the status changed and confirm the current status is shown.
• Record which browsers and which Android versions were tested.

FAQs

Can we launch with only a status view and email? Yes, if your events do not need device level interruption. You can add device alerts later for the one or two events that justify them.

Does showing a browser notification mean we have push? Not necessarily. Showing a message from an open page differs from receiving one from your server when the page is closed. Ask exactly which is included in the quote.

Will email cover people who refuse device alerts? Not unless you specify it. Write the rule into the brief, including who may receive that email and why.

Next step

If you want to scope notification behavior for a specific app, start at work with me. Any work is scoped to your project, with an event list and matrix like the one above as the starting point.