AWRA OpsHub Search

Ten Channels and Two That Ship Off

Ten notification channels, one gate deciding whether a message may go out on any of them, and two that ship switched off. Which two, and why, is the most useful thing on this page.

Operations Metrics AWRA OpsHub Team 12 min read

Every channel is free except the two that are not, and those are the two that ship off.

Our take

The decision that makes a multi-channel notification system usable is what each channel defaults to, and the rule here is that anything with a per-message cost or a genuine interruption cost starts switched off. Text messages and messaging apps that reach a personal phone are in that group; a team chat channel and an in-app record are not. That is the right line, and it is drawn by asking what happens if somebody enables a noisy notification type without thinking rather than what is technically available. The other decision worth noting is architectural restraint: email was not migrated into the new mechanism, it is delegated to. One channel keeps its own storage, behaviour and settings screen, and the new gate defers to it rather than reimplementing a working thing.

The ten, and their defaults

Channel Ships as Why
In-app On The base record every other channel fans out from. Disabling it is possible and unusual.
Email On The established channel, with its own settings and cadence behaviour.
Slack On A team channel. Free, and read at work.
Microsoft Teams On The same.
Telegram On The same.
Discord On The same.
Google Chat On The same.
Push On Free, and already installed by somebody who chose to install it.
WhatsApp Off Reaches a personal phone, and carries a per-message cost.
SMS Off The same, and more so.

Eight on and two off, and the two are the ones where an ill-considered configuration produces both a bill and an interruption. That is the whole rule, and it is stated in one line beside the list: channels sensitive to cost or noise default off.

The in-app record is the base, not a channel like the others

Every other channel fans out from the in-app notification, which is why it is always allowed unless somebody deliberately disables it. That ordering matters for a practical reason: a workspace that has switched off every outbound channel still has a complete record of what happened, in the product, for anybody who goes looking. Notifications become quiet rather than absent.

One gate, four questions

Whether a message may go out is decided in one place, by a single call naming the channel, the module, the notification type and the organisation. Four inputs, one answer, and every channel's fan-out asks the same question.

That is the difference between a system where switching something off works and one where it works on some channels. A gate per channel means a preference that was honoured by email and ignored by the chat integration, and the discrepancy is discovered by a customer who thought they had turned something off.

The resolution order

  1. Email is delegated, entirely

    The question is handed to the existing email implementation, which keeps its own storage, its own behaviour and its own settings screen. Nothing about email changed when the unified gate arrived.

  2. With no organisation, the published default applies

    A message with no workspace context — a platform-level notification — falls to the channel's default rather than to permitted or refused.

  3. A stored preference wins

    Where the organisation has expressed a view on this channel for this notification type, that is the answer.

  4. Otherwise, the published default

    An absent preference is not a refusal. It means nobody has said, and the channel's own default answers.

Delegating one channel is a smaller change than migrating it, and a much smaller risk.

Why delegating email rather than absorbing it

This is the piece of engineering judgement worth taking away. Email had a working gate, a cadence mechanism, a storage table and a settings screen that people already used. The unified gate could have replaced all of that and produced one consistent implementation.

It delegates instead. Email behaviour, storage and settings are explicitly unchanged, and the new mechanism defers to them for that one channel. The cost is an asymmetry — one channel works differently underneath — and the benefit is that introducing a system covering nine new channels changed nothing about the one channel every customer already depended on.

Migrations of working systems are where the risk in a project like this actually lives. The nine new channels had no users to disturb; email had all of them.

Cadence, on every channel

Reminder-style notifications get the same treatment on other channels as on email: a check that the channel is enabled at all, then a check that enough time has passed since the last one went out on that channel for that notification type.

Two properties of that are worth naming. The cadence is per channel, so a daily chat message and a weekly text about the same underlying event are expressible. And the enabled check runs first, so a disabled channel never consumes its own cadence — the same principle applied throughout the reminder machinery, where an empty pass leaves the clock untouched.

Scope, not a ceiling

From a gate to a grid

The decision mechanism is in place and consistent. What organisations want next is to see it and set it, and to know what a channel is costing.

The settings grid

Channels across, notification types down, so a workspace configures its whole notification policy on one screen rather than a type at a time.

Per-recipient preferences

Preferences that belong to a person as well as to an organisation, since the person receiving a message is the one interrupted by it.

Cost visibility on the paid channels

What text messages and messaging-app notifications are costing, beside the switch that enables them.

We publish scope, not dates.

Scope notifications

Five questions to ask about notification channels

Which channels ship switched off?

A good answer sounds like

The ones that cost or interrupt.

What ours actually is

Text messages and WhatsApp. Every other channel ships on, because the rule is cost and noise rather than availability.

Is the decision made in one place?

A good answer sounds like

Yes.

What ours actually is

One call naming the channel, the module, the notification type and the organisation, asked by every channel's fan-out.

What happens with no stored preference?

A good answer sounds like

A published default.

What ours actually is

The channel's own default applies. An absent preference means nobody has said, not that it is refused.

Does email behave differently?

A good answer sounds like

Yes, and deliberately.

What ours actually is

Email delegates to its own existing implementation, keeping its storage, behaviour and settings screen unchanged.

Is there a cadence per channel?

A good answer sounds like

Yes.

What ours actually is

Yes, and the enabled check runs first, so a disabled channel never consumes its own cadence.

The notification ledger, precisely

What AWRA OpsHub does today

  • One gate deciding whether a notification may go out, taking the channel, the module, the notification type and the organisation.
  • Ten channels — in-app, email, Slack, Microsoft Teams, WhatsApp, Telegram, Discord, Google Chat, text message and push — each with a published default.
  • Cost- and noise-sensitive channels defaulting off, so text messages and WhatsApp require a deliberate decision.
  • The in-app record always allowed unless explicitly disabled, since every other channel fans out from it and a workspace with everything switched off still has a complete record.
  • Email delegated entirely to its existing implementation, keeping its storage, behaviour and settings screen unchanged.
  • A preference per channel, module, notification type and organisation, falling back to the channel default when absent.
  • A cadence gate per channel mirroring the email one, with the enabled check running first so a disabled channel never consumes its own cadence.
  • A published default answer for messages with no organisation context.

More we can add to your workspace

  • The settings grid — channels across and notification types down — so a whole notification policy is configured on one screen.
  • Per-recipient preferences, since the person receiving a message is the one interrupted by it and organisations differ from individuals here.
  • Cost visibility on the paid channels, shown beside the switch that enables them.
  • A quiet-hours window per channel, so an urgent text at three in the morning is a deliberate choice rather than a consequence of a schedule.
  • A delivery record per channel, answering whether a message actually arrived rather than whether it was permitted.
  • Escalation across channels, so an unacknowledged notification moves from a chat message to something louder.

Where we point you to a specialist

  • We will keep channels that cost money or reach a personal phone switched off by default. A default that is technically available and financially surprising is a default that produces a bill somebody did not choose, and the first experience of a channel should not be an invoice.
  • We will not migrate a working notification channel into a new mechanism for the sake of symmetry. Email had every existing user; the nine new channels had none. Delegating is an asymmetry we can live with, and a migration would have put the risk exactly where the users were.
  • Which notifications your people should receive, and how loudly, is your operational decision. We will provide the channels, the defaults and the gate; deciding that an approval reminder deserves a text message is a judgement about your organisation.

The settings grid is the contained piece here, because the gate, the defaults and the storage all exist and what it adds is the one screen where an organisation can see and set the whole policy at once.

Decide which two you would switch on

Text messages and WhatsApp are off until somebody chooses them, and choosing them well means [picking](/glossary/picking) the handful of notification types that genuinely warrant reaching a personal phone.

Talk through notifications

Frequently asked questions

Why are text messages and WhatsApp switched off?

Because both carry a per-message cost and both reach a personal phone. The rule for defaults is cost and noise rather than availability, so channels that are free and read at work — team chat, push, the in-app record — ship on, and the two that produce a bill and an interruption require a deliberate decision. The first experience of a channel should not be an invoice.

If we switch off every outbound channel, do we lose the notifications?

No. The in-app record is the base every other channel fans out from, and it is always allowed unless explicitly disabled. A workspace with everything else switched off is quiet rather than blind — the complete record is still in the product for anybody who goes looking.

Does email work the same way as the other channels?

Underneath, no — and deliberately. The unified gate delegates email to its existing implementation, so its storage, its behaviour and its settings screen are unchanged. That asymmetry was chosen over a migration because email had every existing user and the nine new channels had none, and migrations of working systems are where the risk in a project like this actually lives.

What happens if we have never set a preference?

The channel's published default applies. An absent preference means nobody has expressed a view, which is a different thing from a refusal — so a new notification type on an enabled channel goes out, and a new one on a channel that ships off does not.

Can we have different frequencies on different channels?

Yes. The cadence is held per channel as well as per notification type and organisation, so a daily chat message and a weekly text about the same underlying event are expressible. The enabled check runs before the cadence check, so a switched-off channel never consumes its own clock and does not delay the first message after somebody turns it on.

Where do we configure all this?

A type at a time today. The single grid — channels across, notification types down — is the piece that is missing, and it is the first item on the list above, because the gate, the defaults and the storage all exist and what remains is the screen that makes the whole policy visible at once.

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.

Search all approved AWRA public help articles.

Open Help Center