Receiving Messages

Receiving and Routing Messages

Inbound messaging receives replies and unprompted messages and processes them with configurable actions — the same shape e-mail inboxes already use.

Where to find it

Architect Panel → Communication:

• Inbound Messaging — the rules and actions applied to what arrives
• Received Messages — what has come in

You need a real number

An alphanumeric sender ID cannot receive. If replies matter, provision a number that can, and expect people to reply whether or not you invited them to.

Rules and actions

Rules decide which messages get which treatment, matching on the sender, the content or the number it arrived at. Actions decide what happens: file against a record, create one, notify somebody, run a workflow.

Match on the number it arrived at where you can. Using a distinct number per service is the most reliable routing you will get, and far more robust than parsing message text.

Matching to a record

Inbound messages are matched to records by phone number, which is why the number index exists. Numbers arrive in inconsistent formats — with and without country codes, with spaces and brackets — so normalisation matters. The Phone Number Index Rebuild task keeps that index current; it ships disabled and runs daily.

The tasks involved

• Inbound Message Drain — processes what has arrived. Every minute.
• Inbound Message Poll (GOV.UK Notify) — fetches from providers that do not push. Every five minutes.
• Phone Number Index Rebuild — keeps number matching working. Daily.

All ship disabled.

Unmatched messages

Decide what happens to a message from a number you do not recognise. Discarding it silently is the worst option — somebody replied to you and you did not read it. Route it to a queue a person actually looks at.

Two-Way Conversations

Once inbound is configured, messaging becomes a conversation rather than a broadcast — which changes what you need to think about.

Where to find it

Architect Panel → Communication:

• Received Messages — the inbound side of the thread
• Message Log — the outbound side

Keep the thread on the record

Both directions should file against the same record so the exchange reads as a conversation. A case where the outbound messages are on the file and the replies are in a separate list is a case nobody can follow.

Somebody must be listening

The commonest failure of two-way messaging is organisational, not technical: replies arrive and nobody is responsible for reading them. Decide who owns the queue and how quickly they respond before you invite anyone to reply.

The WhatsApp session window

WhatsApp allows free-form replies only within a window after the user's last message. Outside it, you must use an approved template. A conversation that stalls because the window closed looks to the user like being ignored, so design flows that keep exchanges within it or fall back to a template gracefully.

Set expectations

Tell people what the number is for and when it is monitored. "This number is not monitored" on an outbound message is honest; silence is not, and somebody in difficulty will message it anyway.

Safeguarding

Where the people you message may be vulnerable, an inbound channel will eventually receive a disclosure or a crisis message. Have a route for that decided in advance — a rule that flags certain content for immediate human attention is worth configuring before you need it.