Mobile appsWorkflow
Push alerts in a business app: design notifications people act on
A push alert is a small interruption with a big promise: something needs you now. When every sync, comment and minor threshold produces a notification, people mute the app and miss the one alert that mattered. We design alerts as part of the business workflow — who owns each event, how urgent it really is, what the person sees on the lock screen and what happens if nobody responds — so the phone becomes a reliable way to act, not another source of noise.
Decide which events deserve a push
List the events your systems already produce: a sensor above its threshold, an approval waiting in ERP, stock below the reorder point, a failed payment, a new lead assigned in CRM. For each one, ask whether someone must act within minutes, within the day or only at the next review. Only the first group earns an interrupting push. The rest belong in a quieter notification, an in-app inbox or a daily summary.
Give every alert type an owner role and a clear action. “Temperature high in cold room 2” is useful when it reaches the person on shift who can check the door; it is noise for the whole company. Filtering also belongs at the source: a threshold that must hold for a few minutes, with a small hysteresis band before it clears, avoids a burst of alerts from one value bouncing around the limit.
Map urgency to the platform’s levels
Android groups notifications into channels, and users can silence each channel separately. Create one channel per alert family with an honest importance level, because the app cannot raise a channel’s importance after the user has changed it. On iOS, interruption levels range from passive to time-sensitive; critical alerts that break through silent mode require a special entitlement from Apple and are reserved for genuine safety cases.
On the sending side, high-priority Firebase messages are meant for notifications the user will see. Using high priority for silent data sync can lead the platform to deprioritise the app’s messages. Matching urgency honestly keeps the urgent path fast.
| Business urgency | Android | iOS |
|---|---|---|
| Act now, safety or loss | High-importance channel | Time-sensitive, critical only with entitlement |
| Act today | Default channel | Active |
| For information | Low channel or in-app inbox | Passive |
Write the alert for the lock screen
The person should understand the alert without unlocking the phone: what happened, where, the current value and the direction of change. “Cold room 2: 9.4 °C, rising, limit 8 °C” beats “New alert”. Keep personal data, customer names and amounts off the lock screen unless the business has decided that is acceptable.
Repeated alerts for the same condition should update the existing notification rather than stack ten copies. APNs supports a collapse identifier and thread grouping, and Android notifications can be replaced by tag and grouped. Tapping the alert should open the exact item, not the app’s home screen.
Show live context when the alert opens
A push payload is a snapshot, and it may be minutes old by the time someone taps it. The screen behind the alert should fetch the current value, show a short trend chart with 1 h, 24 h and 7 day ranges and list recent alerts for the same asset or record. The person can then judge whether the problem is growing, stable or already resolved.
Put the next actions on that screen: acknowledge, assign to a colleague, add a note or photo, open a maintenance order in ERP or call the site. Each action is logged with the user and time, so the office sees who took ownership without asking in a group chat.
Plan for missed alerts and escalation
Push delivery is best-effort. Phones are switched off, in Do Not Disturb, out of coverage or holding an expired token. If the device is offline, APNs keeps only the latest notification for the app, and older ones are lost. Treat the push as a messenger and keep the alert’s real state on the server: open, acknowledged, resolved.
When an urgent alert stays unacknowledged for a set time, escalate to the next person on the rota, then by SMS, call or email if the business needs it. Respect quiet hours and on-call schedules so people off shift are not woken for routine events. Remove stale device tokens regularly, so the list of reachable people stays accurate.
Measure alert load and tune it monthly
Alert design is never finished on launch day. Review the numbers with the people receiving the alerts and adjust thresholds, owners and channels.
- Count alerts per person per shift and flag anyone who receives more than they can reasonably act on.
- Track time to acknowledgement for urgent alerts and look at the cases that escalated.
- List alerts that were acknowledged with no action and decide whether to raise the threshold or downgrade the level.
- Check how many users have muted a channel, because muting is feedback about relevance.
- Confirm that every alert type still has an owner after team changes.
What we build and how it connects
We build the alert service, the mobile screens behind each alert, acknowledgement and escalation rules and the admin view where your team adjusts recipients and thresholds. Alerts can come from our IoT monitoring platform, ERP approvals, inventory levels, CRM assignments or your existing systems through an integration. Acknowledgements and notes flow back, so reports show what happened and how fast it was handled.
The project starts with a one-off setup and implementation fee, followed by a monthly subscription that covers EU hosting, updates and support. New alert types or integrations are estimated at a fixed hourly rate. Bring the list of events you care about and who should act on them; that is enough to scope the first release.
Inside the product
Mobile apps
Follow the references
Sources & inspiration
Sensor Monitor for Jira
Devpost project by Tomasz Witkowski
Monitors external sensor data with alarms, notifications and charts inside an issue tracker.
This independently created project is credited as inspiration. The workflow and implementation guidance in this article are RDC’s analysis.
Put the guide to work
Start with your workflow.
Tell us what your team needs to do, which systems are involved and where the current process slows down.