The hard part of alerting is deciding what not to send.
Any system can push a message to a phone. What separates a control from a nuisance is whether every single event has a named switch, a delivery channel it may and may not use, a cadence that stops a reminder becoming a stream — and a separate control for the person whose bell it lands in. AWRA ships all four, and treats a notification nobody can turn off as a defect rather than a feature.
Everybody has been on both ends of this, and the second one is worse.
An alerting system has exactly two failure modes, and most products are built to avoid only the first. The second is the one that gets somebody fired, because it looks like nothing at all.
Failure one — too loud
The alert everybody has learned to ignore.
Forty-one notifications a day, thirty-eight of which do not concern you, and the three that do arrive in the same colour as the rest. Within a fortnight the team has stopped reading them, and a genuine stockout warning is now indistinguishable from noise. Nobody switched the system off; they just stopped looking, which is worse because the dashboard still says alerts are enabled.
This is what a per-event switch is for. Not so you can mute everything, but so the six things that actually need a human can arrive alone.
Failure two — silently absent
The alert that was never delivered and never reported.
A purchase order sat unapproved for eleven days because the reminder went to a device whose push token expired in March. Nobody knew, because a failed push looks identical to a push nobody acted on. The approval screen says pending; the notification log says sent.
This is why failed deliveries are bucketed by cause rather than counted. A missing token, a revoked permission, a stale registration and a provider outage are four different problems with four different fixes, and lumping them into “failed: 34” means none of them gets fixed.
Ten channels
Every channel is a column, and every event decides its columns independently.
A single “notifications on/off” toggle is not a preference, it is a shrug. The grid is two-dimensional because the real answer is two-dimensional: an SLA breach might deserve a push and a Slack message and no email; a weekly HR digest deserves email and nothing else. The default for each channel is set by how much it costs and who it interrupts.
Channel
Ships as
What it is for
In-app
On by default
The base record everything else fans out from. It is what the bell reads, and it is the one channel that is always there whether or not anything else is configured.
Email
On by default
The channel with a copy you can forward, file and search two years later. It carries its own module-and-event settings so email behaviour never changes when another channel does.
Push
On by default
Mobile push to registered devices, with per-token error codes recorded when a send fails so a dead handset stops looking like an ignored alert.
Slack
On by default
Operational events into the channel a team already watches, so nobody has to keep a second inbox open to run a warehouse.
Microsoft Teams
On by default
Same job, for the organisations where Teams is where work is discussed rather than Slack.
Telegram
On by default
Widely used by field and logistics teams in the markets we serve, and reliable on a weak connection.
Discord
On by default
For the teams that genuinely run operations there, which is more of them than most vendors expect.
Google Chat
On by default
For Workspace organisations, so the alert lands beside the document it is about.
WhatsApp
Off by default
Reaches a personal number and a personal app. Ships off, because the decision to put work notifications into somebody's WhatsApp is yours to make explicitly rather than ours to make for you.
SMS
Off by default
Costs money per message and arrives whether or not there is data coverage. Ships off, for the events where that trade is worth making — a critical variance, an SLA breach on a live incident.
One rule worth knowing, because it explains a design decision. An event that is not in the catalogue cannot be switched off — the gate returns the channel's default when no preference exists, and eight of the ten default to on. So a notification the preferences screen has never heard of pushes to every registered device forever, with no control anywhere. That is not hypothetical: the pooled-asset movement and asset risk alerts behaved exactly that way until they were catalogued. Coverage of the catalogue is therefore tested in both directions — an event with no row, and a row with nothing emitting it.
Cadence, per event, per channel
A reminder that fires every time a job runs is not a reminder. It is a metronome.
Reminder-style notifications — approvals still waiting, RFQs unanswered, purchase orders overdue, batches approaching expiry — are generated by scheduled work that runs far more often than anybody wants to be told. So each one carries its own cadence gate, per channel, and the last time it fired is recorded so the next one knows whether it is due.
Daily1 day
The default. Enough for an approval queue somebody is expected to clear each morning.
Weekly7 days
For digests and anything where the useful signal is a trend rather than an item — the HR summary, the failed-workflow round-up.
Monthly30 days
For the reminders that only become interesting at a reporting boundary, and would be nagging at any shorter interval.
CustomN days
Any interval in days. Set it to 3 for a fortnightly approval cycle, or 14 for a quarterly review that needs two nudges.
The cadence gate sits after the on/off gate, which is the correct order and worth stating: switching an event off silences it regardless of cadence, and a cadence never resurrects something you turned off. The pair is also per channel, so the same overdue-purchase-order reminder can be a daily push and a weekly email without anybody maintaining two schedules.
What can be raised
The catalogue, module by module. Every line below is one switch.
This is the actual list rather than a representative sample, because the point of a catalogue is that it is complete. Where an event has been emitted historically under a different name, the old name is mapped onto the existing row instead of growing a second near-duplicate switch — so turning something off turns it off once, not twice.
Decisions waiting
Approvals
Pending approval inbox digest
Requests, RFQs & orders
Procurement
Request submitted
Request status changed
Request checked out to stock
Requests awaiting approval
RFQ submitted for approval
RFQ approved
RFQ rejected
RFQs expiring or unanswered
Purchase orders overdue for delivery
Vendor responses & awards
Quotations
Vendor quote submitted
Quotation approved
Quotation partially approved
Quotation rejected
Purchase order sent to vendor
Purchase order cancelled
Quotation expiry reminder
Check-in, check-out & stock risk
Inventory movement
Check-in approval reminder
Check-out approval reminder
Check-in adjustment created
Check-out adjustment created
Low stock alert & reminder
Batch expiry alert (30/60/90-day horizon)
Catalogue governance
Item master
Item created
Item master change awaiting approval
Item master change approved
Supplier record & portal
Vendors
Vendor added
Vendor updated
Vendor deleted
Vendor portal invitation resent
RFQ sent to vendor
Custody & pooled movement
Assets
Pooled asset movement awaiting approval
Pooled asset movement approved
Pooled asset movement rejected
Asset risk event recorded — loss, damage, theft
Billing & collection
Customer invoices
Customer invoice fulfilled
Overdue invoice admin digest
Overdue invoice reminder (to the customer)
Money in
Payments
Payment received
Tenant registration confirmation
SLA & workforce
HR & people
HR KPI target breach
Overdue leave approvals (SLA)
Overdue attendance regularizations (SLA)
Missing clock-out — HR digest
Missing clock-out — notify the employee
Weekly HR summary digest
Task & delivery
Projects
Task assigned to you
Task status changed
Task due soon or overdue
Mentioned in a task
Updates on tasks you watch
Project payout posted
Tickets & SLA
Helpdesk
Ticket assigned to you
New reply on a ticket
Ticket status changed
New ticket in your department queue
Updates on tickets you watch
First-response SLA breach
SLA breach & escalation
Access events
Security
Security / device login digest
Automation health
Workflows
Failed workflow, webhook & integration digest
Scheduled delivery
Reports
Scheduled report email
Account lifecycle
Users
New user welcome email
User profile updated
Support conversation
Messages
Chat message notification
AWRA reply notification
Tenant lifecycle
Workspace
Workspace deletion reminder
Plan expiry / billing risk reminder
Kept separate on purpose
Product email
Getting started series (first 30 days)
Win-back emails
Renewal value summary
Monthly value recap
Unused-feature nudge
Monthly product & guides digest
Occasional review request
Why the last card is separate. Product and engagement email — the getting-started series, the win-back sequence, the monthly recap — is deliberately not filed with operational mail. Switching off the marketing never silences an invoice reminder or an approval request, and switching off approvals never stops the onboarding series. Individuals can also unsubscribe themselves from any of it from the email footer without touching an admin setting.
The feed is a separate decision
The person configuring the channels is almost never the person drowning in the bell.
Channel preferences are a workspace decision: what the organisation sends, where, how often. What appears in your notification feed is a personal one, held per user, with twenty-six filters grouped into ten families. A storekeeper can hide project-task chatter without an administrator being involved, and without affecting anybody else's feed.
Notifications4 unread
Low stock — Diesel generator filter kit8 units, reorder point 20 · Nairobi Central Store
Item master change awaiting approvalBarcode change on “Latex gloves, box of 100”
Pooled asset movement approved12 × folding chair → Kisumu branch
Purchase order overdue for deliveryPO-2026-0912 · 6 days past promised date
New device login detectedHidden by your feed settings — default off
The last row is the one worth pointing at: new-device login alerts are catalogued and default to hidden in the feed, because for most people they are noise and for a few they are essential. They are one toggle away, on your own settings screen, and nobody else's feed changes when you flip it.
Ten families, twenty-six filters.
Approvals split three ways — requests, accepted, rejected — because the person who wants to know when something needs deciding is often not the person who wants to know it was decided. Inventory splits five ways: item changes, check-ins, check-outs, other adjustments, and stock risk. Then procurement, vendors, sales and finance, assets, helpdesk, risk and exceptions, security and account, and everything else.
Marking everything read respects the filter, which is a small thing that matters: a “mark all read” that also clears the categories you have hidden would silently consume the notifications you chose not to see.
“Failed: 34” is not a diagnosis. Five buckets are.
A push that never lands has a cause, and the cause determines who fixes it and how. So every failed send is bucketed, per-token error codes from the provider are stored rather than discarded, and the last thirty days are summarised — including the sends that failed because there was no device to send to, which is the case most systems do not count at all.
Bucket
What actually happened
Who fixes it
missing_token
There was no registered device to send to. The send did not fail in transit — it never had a destination. Counting these as successes is how a team concludes push is working when nobody has the app installed.
The user, by signing in on the app
configuration
The push credentials are absent or wrong, so nothing can be delivered for anybody. One finding here explains every other failure on the page.
An administrator, once
permission_denied
The device declined notification permission, or the person revoked it in their OS settings. The token exists and is useless.
The user, in device settings
stale_token
The registration is no longer valid — app reinstalled, device wiped, token rotated. Stale registrations are listed so they can be cleared instead of accumulating as permanent failures.
Housekeeping, from the list
provider_error
The push provider rejected or could not deliver the message for its own reasons. This is the bucket that is genuinely not your fault, and separating it out is the point.
Nobody — retry or wait
Where a single send touched several devices and failed on some of them, the per-device error codes are kept individually rather than collapsed into one verdict for the batch. A notification that reached three phones and failed on a fourth is a different situation from one that failed on all four, and only one of them is urgent.
The straight answer
Where the switchboard ends, precisely.
Notification systems are easy to oversell because nobody audits them until something is missed. Here is what is real, what we would build on request, and where we would rather point you elsewhere.
Notifications & channels — what is real
What AWRA OpsHub does today
Ten delivery channels — in-app, email, push, Slack, Microsoft Teams, Telegram, Discord, Google Chat, WhatsApp and SMS — each with its own default, and the two that cost money or reach a personal app shipping switched off.
A catalogued event list of 75-plus named notifications across nineteen module groups, every one of them switchable per channel, with historical name variants aliased onto the existing row so one switch controls one event.
A per-event, per-channel reminder cadence — daily, weekly, monthly or any custom interval in days — with the last fire time recorded so a scheduled job cannot turn a reminder into a stream.
A separate per-person feed filter with 26 toggles in ten families, so an individual can quieten their own bell without an administrator and without changing anybody else's.
Push failure diagnostics in five buckets with per-device error codes stored, a thirty-day summary, a stale-token list, and zero-device sends counted as failures rather than successes.
Email settings held separately from the other nine channels, so email behaviour, storage and its own settings screen never shift when a chat channel is reconfigured.
Product email kept apart from operational email, so switching off the onboarding series never silences an approval request — and individuals can unsubscribe themselves from any email footer.
Catalogue coverage tested in both directions — an event with no switch, and a switch with nothing emitting it — because both are silent defects.
Deep links carried in the notification, so a mobile alert opens the approval it is about rather than the app's home screen.
The same preference API on web and mobile, read from one source, so the app can configure exactly what the browser can.
More we can add to your workspace
Per-user channel routing — today the channel grid is a workspace decision and the feed filter is the personal one. Routing a specific event to one named person's Slack and another's SMS is a scoping conversation about how your teams are actually structured.
Quiet hours and an on-call calendar, so an out-of-tolerance variance at 02:00 reaches whoever is actually on duty rather than everybody who holds the permission.
Escalation chains on unacknowledged alerts — if nobody opens the SLA breach within twenty minutes, it climbs.
A digest builder that rolls several events into one message on a schedule you compose, beyond the fixed digests that ship today.
Per-event delivery receipts across every channel, of the kind the push path already produces, so a Slack post that silently failed is as visible as a failed push.
A notification simulator that fires a test of any catalogued event on any channel, so a new configuration can be proved before the real event happens.
Localised notification copy per recipient language, with the templates and translation workflow that implies.
Where we point you to a specialist
We will not add an event that has no switch. A notification the preferences screen has never heard of pushes to every registered device forever, because the gate falls back to the channel default and most channels default on. That is a defect, it has bitten this product before, and it is now tested for in both directions rather than trusted.
We will not default SMS or WhatsApp to on. Both reach a person on a channel they use for their own life, and one of them bills you per message. Turning them on should be a decision somebody makes on purpose, with a specific event in mind.
We will not present a delivered notification as a read notification. The push diagnostics tell you what left and what failed. Whether a human looked at it is not something a server can know, and a vendor implying otherwise is selling you comfort.
We will not treat alerting as a substitute for a control. A low-stock notification is not a stock policy and an SLA warning is not an SLA. If the thing must not happen, it belongs in an approval gate or a validation rule, not in a message somebody may be ignoring.
Quiet hours, on-call routing and escalation chains are the three most-asked items in that middle column, and they are one design conversation rather than three builds — the hard part is your rota, not the code. Tell us how your out-of-hours cover actually works and we will come back with a written spec, a timeline and a price.
What it connects to
A notification is the last three inches of something that happened somewhere else.
That is the whole measurable outcome, and everything above is in service of it. An alerting system is working when a message arriving means something, and it is broken when it means nothing — regardless of how many channels it supports.
Turn off the forty events nobody acts on and the six that matter stop arriving in camouflage.
Nothing is unswitchable
Every event has a named row. If it reaches you, there is a place to stop it reaching you.
Reminders stop nagging
A cadence per event means the overdue-order reminder arrives daily and the HR digest weekly, without two schedules.
A failed push gets diagnosed
Five buckets and a per-device error code, so "he never got it" has a cause and an owner.
Individuals fix their own bell
Twenty-six personal filters, no admin ticket, no effect on anybody else.
Marketing never silences operations
Two separate settings families, so unsubscribing from a product email leaves the invoice reminder alone.
Frequently asked questions
Which notification channels are supported?
Ten: in-app, email, mobile push, Slack, Microsoft Teams, Telegram, Discord, Google Chat, WhatsApp and SMS. In-app is the base record every other channel fans out from. Eight of the ten default to on; SMS and WhatsApp default to off, because one bills you per message and both reach a person on a channel they use for their own life. Every channel can be switched on or off independently for every catalogued event, so an SLA breach can push and post to Slack without sending an email, and a weekly digest can email and nothing else.
Can we turn off individual notifications rather than whole categories?
Yes — that is the design. Every event the system can raise has a named row in a catalogue, and the preferences grid crosses those rows with the delivery channels. There are more than 75 rows across nineteen module groups. Where an event has historically been emitted under a different internal name, the old name is mapped onto the existing row rather than growing a second near-duplicate switch, so switching something off switches it off once.
How do you stop a reminder becoming a stream of identical messages?
Reminder-style notifications — approvals still waiting, RFQs unanswered, purchase orders overdue, batches approaching expiry — carry their own cadence gate per event and per channel: daily, weekly, monthly, or any custom interval in days. The last time each one fired is recorded, so the scheduled job that generates them can run as often as it needs to without the recipient hearing about it every time. The cadence gate runs after the on/off gate, so switching an event off silences it regardless of cadence.
Can an individual quieten their own notification feed without an administrator?
Yes, and it is a separate mechanism from the channel grid on purpose. Channel preferences are a workspace decision about what gets sent and where. What appears in your bell is personal, held per user, with 26 filters grouped into ten families — approvals split into requests, accepted and rejected; inventory split into item changes, check-ins, check-outs, other adjustments and stock risk; then procurement, vendors, sales and finance, assets, helpdesk, risk and exceptions, security and account, and other. Marking everything read respects your filter, so it never quietly consumes the categories you chose to hide.
How do we know whether a push notification actually arrived?
Failed sends are bucketed by cause rather than counted, into five categories: no registered device to send to, missing or wrong push configuration, permission declined or revoked on the device, a stale registration from a reinstalled or wiped handset, and a provider-side error. Per-device error codes from the provider are stored rather than discarded, the last thirty days are summarised, and stale registrations are listed so they can be cleared. Sends that failed because there was no device at all are counted as failures — most systems record those as successes, which is how a team concludes push is working when nobody has the app installed. What none of this can tell you is whether a human read the message; that is not something a server knows.
Will switching off marketing email also stop operational alerts?
No. Product and engagement email — the getting-started series, win-back messages, the monthly value recap, the unused-feature nudge, the product digest and the occasional review request — is filed separately from operational mail. Turning the marketing off leaves invoice reminders, approval requests and SLA warnings alone, and turning operational alerts off does not stop the onboarding series. Individuals can also unsubscribe themselves from any of the product email directly from the footer of the email, without an administrator changing a setting.
What happens if a new notification is added and nobody catalogues it?
It would push to every registered device forever with no control anywhere, because the delivery gate returns the channel default when no preference row exists and eight of the ten channels default to on. That is a real defect this product has shipped before — the pooled-asset movement and asset risk alerts behaved exactly that way until they were catalogued. It is now tested in both directions: an emitted event with no catalogue row fails the build, and so does a catalogue row with nothing emitting it, because a switch that does nothing is its own kind of lie.
Are notification preferences configurable from the mobile app?
Yes, and from the same source of truth. The catalogue and the channel list are read by the web controller, the API controller and the mobile settings screen, so the app can configure exactly what the browser can. This was not always true — an earlier hand-maintained copy of the list in the API was missing all of helpdesk, most of HR and all of projects, which meant the phone could not switch off notifications the browser could. Both now read one method, so the lists cannot drift apart.
Help Center
Need a quick answer while you read?
Run inventory, procurement, assets, sales, and field work with approved AWRA guidance for setup, migration, integrations, security, pricing, and support.
Demo booking
Book a focused AWRA demo
Share a few details so we can send the confirmation email and route your request to the right AWRA team.
1
Request received AWRA has your demo context and contact details.
2
Check your email We send confirmation and follow-up from the AWRA team.
3
Book calendar slot Pick a time for a focused workflow walkthrough.
We use necessary cookies for secure sessions. With your permission, we also use cookies and browser storage for preferences, analytics, and demo engagement. Privacy Policy
AWRA OpsHub
Cookie settings
Cookie Consent Manager
Necessary cookies stay on for login, CSRF protection, and security. You can choose the optional categories below.
Overview
General Information
AWRA uses cookies and browser storage to keep public pages secure, remember selected preferences, measure website performance, and manage demo engagement prompts.
You can choose whether functional and marketing engagement storage apply. Analytics measurement is always active in this AWRA setup.
These settings apply to AWRA public website experiences such as the homepage, feature pages, pricing calculator, blog, help center, and request-demo page. Authenticated dashboard and vendor portal sessions still rely on required security cookies.
Required
Always active
Functional
Optional
Analytics
Always active
Marketing
Optional
For more context on privacy handling, open the Privacy Policy.
Required Cookies
Required Cookies
Always Active
Required cookies and storage support basic website delivery, secure sessions, request protection, and remembering the consent choice itself.
These cannot be switched off from this manager because disabling them would break login/session behavior, form protection, or the ability to remember the privacy choice you save.
Cookie details
Session security: keeps secure server sessions working while browsing AWRA.
CSRF protection: helps verify form submissions and protect requests.
Consent record: stores the preference decision so the banner does not keep asking after a choice is saved.
Examples: Laravel session cookies, CSRF tokens, and the AWRA consent preference record.
Duration: session security can expire with the browser/session; saved consent can last longer so the same browser remembers the choice.
Functional Cookies
Functional Cookies
Functional storage improves the public website experience by remembering interface choices, helper states, dismissed notices, and short-lived interaction preferences.
Turning this off does not stop secure required cookies or analytics. It only limits optional convenience memory.
If disabled, AWRA may show some helper prompts again or forget non-essential display choices. Core public pages, contact forms, and request-demo forms still work.
Cookie details
UI preferences: remembered display choices and helper states where available.
Dismissed notices: session-level or preference-level memory for notices the visitor has closed.
Frequency helpers: optional browser storage that prevents repeated prompts when allowed.
Examples: localStorage or sessionStorage values for dismissed banners, guide/helper states, and lightweight public-page preferences.
Effect when off: AWRA avoids optional convenience memory unless it is also allowed through marketing and engagement preferences.
Analytics Cookies
Analytics Cookies
Always Active
Analytics helps AWRA understand public page performance, traffic patterns, and content usefulness so we can improve the marketing website.
This category does not by itself enable demo popups, exit-intent prompts, or advertising pixels. Those are controlled by Marketing & engagement.
In this AWRA setup, Google Analytics and Google Tag Manager measurement are treated as mandatory website measurement and remain active.
Cookie details
Google Analytics / GTM: measures aggregate traffic and page activity.
Performance insight: helps identify which public pages, docs, and demo paths visitors use.
Operational signal: supports website quality decisions without enabling demo popups by itself.
Examples: Google measurement identifiers such as GA/GTM tags and related browser identifiers set by Google scripts.
Use: page views, source/referrer trends, public content performance, and product education page effectiveness.
Marketing & engagement
Marketing & engagement
Marketing and engagement storage supports demo prompts, exit-intent prompts, campaign attribution, and future advertising pixels.
When disabled, AWRA will not auto-open demo or exit-intent popups. CTA buttons can still open a form because that is a direct visitor action.
When enabled, AWRA can remember that a visitor already saw, dismissed, or submitted a demo prompt so the same popup is not repeated aggressively.
Cookie details
Demo prompt memory: tracks whether an auto prompt or exit prompt was recently dismissed.
Demo submission memory: avoids asking again after a visitor submits a demo request.
Campaign context: keeps source page, referrer, and UTM context available for demo requests.
Examples: popup frequency caps, demo-submitted flags, engagement source fields, and UTM/referrer context.
Effect when off: auto demo prompts and exit-intent prompts stay blocked; normal navigation and manually clicked CTA buttons still work.
