Never guess which account a message belongs to

Inbound messages are routed to an account only when the answer is unambiguous; anything shared or unclaimed is stored under a holding tenant for a human to assign rather than filed into the wrong business.

What it is

Two resolvers. Numbers resolve through the number inventory to an account and, when the number belongs to a rep, that rep. Email resolves by a VERP address that names the account outright, otherwise by domain — and only when exactly one account claims that domain. Two claimants returns ambiguous. Messages are always written first; matching and notification are best-effort enrichment.

Also called: ambiguous domain · shared sending domain · unrouted message · wrong inbox · VERP

See it
Never guess which account a message belongs to
Area
Integrations
Group
Inbound routing
System
Inbound Messaging
Solves
3 named problems
01For phone: the called number is normalised and looked up in org_phone_numbers, with a legacy binding fallback.
02For email: a plus-addressed local part naming the org wins outright.
03Otherwise the recipient domain must belong to exactly one account.
A routing decision tree ending in three outcomes: matched account, matched rep, or 'held for triage' with the reason shown. Sample data — no customer information appears here.
How it works
  1. 1For phone: the called number is normalised and looked up in org_phone_numbers, with a legacy binding fallback.
  2. 2For email: a plus-addressed local part naming the org wins outright.
  3. 3Otherwise the recipient domain must belong to exactly one account.
  4. 4Ambiguous or unclaimed messages are stored under the sentinel tenant with the reason recorded.
  5. 5Deduplication is a unique index on provider plus provider message id.
Why we built it

The rule is stated as absolute: 'THIS MUST NEVER GUESS. Six live orgs share the sending domain mail.pfbuild.com, so a first-match-wins scan — which is what this did originally — can file one builder's customer reply into another builder's inbox. That is the cross-tenant isolation rule, and it is absolute: there is no acceptable rate of leaking one tenant's mail to another... Holding a message for triage is recoverable; misfiling it into a competitor's inbox is not.' The write-first rule is stated too: 'A text from a number nobody recognises is still a text.' The phone resolver's rewrite is recorded as well — the old version 'pulled every twilio binding in the database and compared a config string in a loop, which was a full scan of all tenants on every inbound text and could only ever find one number per account.'

The problem
  • A shared sending domain could misfile one builder's reply into a competitor's inbox.
  • Unrecognised numbers dropped messages entirely.
  • Inbound routing scanned every tenant's binding on every message.
Sound familiar?
What you get
Cross-tenant misfiling is structurally impossible.
Nothing is ever dropped — unroutable mail is held for triage.
A reply to a rep's number lands with that rep.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →