Verifying a channel actually works
Send one real message in each direction and watch where it lands. A saved credential proves somebody typed something; a health indicator proves a connection was accepted. Neither proves that a customer's message reaches the right workspace, attaches to the right person and produces the decision you expect. Only traffic proves that, and each channel has a different half it cannot prove.
The chain#
- Trigger — a channel has just been configured, or a provider behind one has changed, or something is behaving oddly and nobody is sure the channel is at fault.
- User event — a person sends a real message from an address or number outside the workspace. A message the workspace sends to itself proves far less, because it can succeed on a loop that never touches the provider's inbound path.
- Authentication and workspace resolution — the inbound event should resolve to exactly one workspace. If it resolves to none, the failure is routing and everything downstream is untested.
- Ingest — the payload is normalised into the canonical shape. This is the first stage with visible evidence: the message exists or it does not.
- Canonical record — a conversation and a message. Check the timestamp is the provider's rather than the moment of processing, which is what tells you a delayed message is not silently claiming to be recent.
- Classification — the engine triages it. A message that arrives and is never picked up points at the engine or the workspace's rules, not at the channel.
- Knowledge, memory and rules — watch whether the standing instructions you set are visibly reflected in what is proposed. A signature, a business-hours rule or a directive that is ignored is worth catching now.
- Autonomy and approval — confirm the mode you intended is the mode in force. A reply that goes out when you expected an approval queue is a configuration error, not a surprise to absorb.
- Action through a provider — the outbound half. On email, WhatsApp and phone this completes; on SMS it cannot, because the live carrier carries no SMS.
- Result — provider evidence, not optimism. A send counts as sent when the provider acknowledges it, and the record should show that acknowledgement rather than an intention.
- Relationship and timeline — the exchange should be on the right Person, beside their other channels. A new contact where you expected a match is an identity problem worth fixing before it multiplies.
- Audit and usage — the decision, its rule and the metering should all be present. An action with no audit entry is the one result worth escalating immediately.
- Next — repeat as the other audience. A channel verified only as the Owner has been verified for one of the two doors.
The test per channel, and its blind spot#
| Channel | The test | What it proves | What it does not prove |
|---|---|---|---|
| Send from an outside address; watch it arrive, then approve a reply | Fetch, canonicalisation, threading, the send boundary and provider evidence | Deliverability to a stranger's inbox, or behaviour on a mailbox with a large backlog | |
| Message the business number from a personal one and read the reply | Webhook, person resolution, continuity and the reply path | Template approval, session-window behaviour outside the window, media and delivery reporting | |
| Phone | Ring the business number and hold a short conversation | Routing, the engine, transcript and summary | Behaviour under load, and anything the carrier does not carry |
| SMS | Text the business number and watch it attach to the right person | Webhook, deduplication, attachment and opt-out | Sending — no outbound text is possible on the live carrier, so half the channel is untestable here |
Why a green screen is not evidence#
A connection indicator answers one question: did the provider accept a credential. It does not answer whether messages are being fetched, whether a cursor has stalled, whether routing points at this workspace, or whether the reply path works. Those are separate failures with the same reassuring appearance, which is why Why 'connected' is not enough to prove mailbox health exists as a note in its own right.
The same caution applies to a test harness. Replaying a stored payload exercises the code after ingest and proves nothing about whether a provider can reach you, which is the part that actually breaks. Verify with a message that crossed the public network.
Verify as both audiences#
Run the test once with an Owner session.
Result You have proved the operator path — the direct routes.
Run the same test with a customer session in the workspace that matters.
Result You have proved the tenant facade too. An unrecognised path is rewritten to
blockedand answers 403, which looks like a broken feature and is a routing gate.Compare what each audience sees on the screen, not only what the API returned.
Result Some defects are invisible in the source and obvious in a browser — an element covered by something else is still an element the customer cannot use.
Questions#
How often should a channel be re-verified?
After any provider or credential change, and after any incident that touched routing. A channel that has been quiet for a long time is also worth a test: silence is ambiguous, and a mailbox nobody writes to looks identical to one that has stopped fetching.
Can I verify without a customer seeing anything?
Use your own address or number as the outside party. That exercises the real provider path without involving anybody's customer, and it is the only part of the test that has to touch the public network.
What is the single most common false pass?
Concluding a channel works because a settings screen saved without an error. The second most common is testing only the inbound half on a channel where the outbound half is the one in question.