SMS & WhatsApp

Connecting a Messaging Provider

Messaging sends text and WhatsApp messages from workflows, campaigns and the platform's own two-factor and password-reset paths.

Where to find it

Architect Panel → Communication:

• SMS & WhatsApp Accounts — providers, credentials and sending numbers
• GOV.UK Notify Templates — where you send through GOV.UK Notify
• Message Log — everything sent, and what happened to it

Providers

Several provider families are supported, including Twilio, AWS (SMS, SNS and WhatsApp), Meta for WhatsApp, ClickSend, GOV.UK Notify and a generic HTTP driver for anything else. Public sector organisations already using GOV.UK Notify can keep it.

Every provider ships disabled and without credentials. Enable the one you use and supply your own.

Setting one up

1. Add the account, choose the provider and enter its credentials.
2. Configure the sending number or sender ID. Alphanumeric sender IDs are not permitted everywhere and cannot receive replies — if you want two-way messaging you need a real number.
3. Send a test to your own handset before wiring it into anything.

WhatsApp is not SMS

WhatsApp requires pre-approved message templates for anything you initiate, and a session window within which you may reply freely. Plan for the approval step — it takes days, not minutes, and a campaign scheduled before templates are approved will not send.

Cost

Messages cost money per send, and a workflow that sends on every save of a busy datastore will find that out quickly. Check the trigger before enabling anything that sends automatically.

Sending Messages

Once an account is configured, sending happens from several places and all of them land in the same log.

Where to find it

Architect Panel → Communication:

• Message Log — every message, its state and its cost

Where to find it

Architect Panel → Activity:

• SMS Log — the sending record from the platform side

Where sends come from

• Workflows — a send action at a stage, which is how most operational messaging works: an appointment reminder, a status change, a code.
• Campaigns — a bulk send to a selected audience.
• Platform paths — two-factor codes and password resets, which use the same accounts.

Delivery is not immediate

A message is queued, dispatched and then reported on by the provider. The states matter: accepted by the provider is not delivered to the handset, and delivered is not read. Build any process that depends on a message on the state you actually have.

The drain task

Outbound dispatch and inbound processing are driven by the Inbound Message Drain task, which ships disabled and should run every minute. Messaging that appears to do nothing at all is almost always this task not being enabled.

Message content

Keep it short and identify yourself. A message that does not say who it is from reads as spam, and recipients report it. Include a way to stop — both because people expect it and because it keeps your sending reputation intact.

Timing

Do not send outside reasonable hours. A two-factor code at 3am is fine because the user asked for it; a marketing message is not, and a reminder is arguable. Where the send is scheduled rather than triggered, constrain the window.

Opt-Outs and Suppression

Suppression is the list of people who must not be messaged. Getting it right is both a legal obligation and what keeps your sending numbers usable.

Where to find it

Architect Panel → Communication:

• Message Opt-Outs — the suppression list

Stop requests are automatic

An inbound message saying STOP adds the number to suppression without anyone intervening. That is the behaviour recipients expect and regulators require, and it happens whether or not you have configured anything else about inbound messaging.

Suppression survives your data

The list is separate from your contact records deliberately. Deleting a contact and re-importing them does not resurrect consent, and it must not — re-messaging somebody who opted out because a spreadsheet was re-imported is the classic way an organisation ends up explaining itself.

Check before sending, not after

Suppression is applied at send. You do not need to filter your audience by hand, and you should not try — a campaign audience built with its own exclusion logic will eventually diverge from the real list.

Transactional versus marketing

The rules differ, and so should your handling. A two-factor code to somebody who opted out of marketing is normally legitimate; a promotion is not. Be careful that a message described internally as a service notification is not marketing wearing a different name.

Review it

Look at the suppression list occasionally. A sudden rise in opt-outs is telling you something about the messages being sent — usually frequency — and it is much cheaper to learn that from your own list than from a regulator.