Notification Services

The ten channels#

For the properties each declares, see the Connection Property Reference approach — notification servers are configured in the Deployment view alongside other service objects.

Notification servers are deployable service objects#

A notification server sits on a Platform and is hosted by Flow Bootstrap, like the Data Engine and Flow Server. That means:

• It must be deployed before it delivers anything. A configured-but-undeployed notification server is the most common cause of "the alerts stopped".
• It runs as the Bootstrap service account, which matters for anything needing local credentials — a file drop to a network share in particular.
• It can be placed on whichever Platform has the network access it needs. A channel reaching an internal SMTP relay can live on a Platform inside that network.

See Deploying Configuration.

Choosing a channel#

The channel should match the urgency and the audience, and the mistake almost everyone makes is sending everything by email.

Two observations from practice.

Chat channels are better than email for team-level alerting. A Teams or Slack channel is visible to a group, is already open on their screens, and creates a conversation thread where someone can say "I'm on it". Email produces twelve individual notifications and no coordination.

SMS should be rare and genuinely urgent. It interrupts, it costs money per message, and it has no context — a few words with no dashboard link. Reserve it for the small number of conditions where waking someone is justified. A plant that sends routine notifications by SMS teaches people to ignore SMS.

Email#

The most-used channel, and the one with the most operational gotchas.

• Authentication. Modern mail platforms increasingly refuse basic SMTP authentication. Check what your mail provider requires before assuming a username and password will work.
• A dedicated sending identity. Send from an address that exists for this purpose, not from a person's mailbox. When that person leaves, the notifications should not.
• Deliverability. Messages from a server that is not an expected sender for your domain can land in spam. This is a mail-infrastructure conversation, and it is worth having before rollout rather than after a month of unnoticed alerts.
• Reply behaviour. People will reply to notifications. Point replies somewhere a human reads, or make it clear in the message that nobody does.

Teams, Slack, and Telegram#

Configured against a channel or a chat, usually with a webhook or a bot credential.

Practical notes:

• One channel per purpose, not one channel for all Infohub output. A channel receiving both routine daily summaries and genuine alarms trains people to skim it.
• Credentials expire. Webhooks and bot tokens get rotated or revoked, sometimes by someone tidying up an unrelated integration. A channel that has gone quiet is worth checking against the credential before assuming nothing has happened.
• Formatting is limited. Chat channels favour short messages with a link into Infohub. Do not try to reproduce a report in a chat message.

SMS: Twilio, SMSPortal, Bulk SMS#

Three providers for the same job. Choose on commercial and regional grounds — coverage, cost, and which provider your organisation already has an account with.

Whichever you use:

• Messages cost money. A misconfigured alarm that fires every five minutes has a directly measurable cost, which is at least a fast way to discover the misconfiguration.
• Keep them short and specific. "Boiler 1 pressure high, 1.62 MPa, 14:20" is actionable. "A limit has been exceeded" is not.
• Number formatting matters. International format, with the country code, saves a class of silent delivery failure.
• There is no read receipt. Do not build a process that assumes an SMS was seen.

File Drop#

Writes output to a folder or share rather than sending it to a person. Two good uses:

Handing off to another system. A file another application collects — a nightly extract, a report an intranet publishes.

Large scheduled reports. A monthly pack that is too large to email comfortably, written to a shared location by convention.

The thing that catches people: the file drop runs as the Bootstrap service account, so that account needs write access to the destination. A path that works from your workstation proves nothing about the service. Use a UNC path, not a mapped drive letter — drive mappings are per user and the service will not have them.

Flow Mobile#

Push notifications to the Flow mobile app, which is the right channel for someone who needs to know while away from a desk and does not warrant an SMS.

Because it delivers into an app that can then show the data, it is better than SMS for anything where the recipient will want context — they receive the alert and can open the dashboard behind it.

Redundancy#

For genuinely critical conditions, use two channels. A single channel has a single point of failure: an SMTP relay down, an expired webhook, a phone out of signal.

Two channels for the small number of conditions that matter, and one for everything else, is the right balance. Two channels for everything doubles the volume and accelerates the muting problem.

Diagnosing#

See also#

• The Message Engine
• Flow Mobile
• Building an Alarm Strategy
• Exporting and Scheduling Reports