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, so if you have configured one you know this.
Where to find it
Architect Panel → Communication:
- Inbound Messaging — the console — rules and actions applied to what arrives
- Received Messages — what has come in, and what happened to it
You need a real number
An alphanumeric sender ID cannot receive. If replies matter, provision a number that can.
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 wherever you can. Using a distinct number per service is the most reliable routing available and far more robust than parsing message text — people do not write what you expect.
Matching to a record
Inbound messages are matched to records by phone number, which is why a number index exists. Numbers arrive in inconsistent formats — with and without country codes, with spaces, brackets and leading zeros — so normalisation matters.
The Phone Number Index Rebuild task keeps that index current. It ships disabled and runs daily. If inbound messages stop matching records after a bulk import, this is the first thing to check.
The three tasks
- Inbound Message Drain — processes what has arrived. Every minute.
- Inbound Message Poll (GOV.UK Notify) — fetches from providers that do not push to you. Every five minutes.
- Phone Number Index Rebuild — keeps number matching working. Daily.
All ship disabled under Automation → Tasks.
Unmatched messages
Decide what happens to a message from a number you do not recognise, and decide it before you go live.
Discarding silently is the worst option: somebody replied to you and nobody read it. Route unmatched messages to a queue a person actually looks at, and check that queue is genuinely owned rather than nominally owned.
Worked example
A council uses one number for bin collection alerts and another for council tax. Rules route by receiving number, so a reply to a bin alert never lands in a council tax queue. Unmatched messages — someone texting from a number not on the record — go to a customer services queue, where they are matched by hand and the number added.
Recommendations
- One number per service where you can afford it. It is the cheapest routing you will ever configure.
- Own the unmatched queue explicitly. Name a team, not "customer services generally".
- Rebuild the number index after bulk imports.
- Test with a real handset, including a reply, before going live.