The honest answer to 'who carries this channel': active provider bindings in priority order, or, when there are none, the platform default chain clearly flagged as inherited. Tenant admins can read their own; changing it is a platform action.
Also called: email provider · sms provider · who sends my messages · switch providers
- 1The matrix answers the question the way the SENDER answers it — active bindings in priority order, falling back to the default chain
- 2An inherited default is labelled as inherited so nobody mistakes it for a decision
- 3It is read-only and derives everything, importing the default chains from the registry rather than restating them
- 4Reading is open to a tenant admin for their own account only; the account id is never taken from the request for a tenant
One account's texting had been running fine through a connected CRM for months while the console reported it as unconfigured, because it was reading the wrong thing — and a console that says "not set up" about a channel a customer is actively using is worse than no console, because it invites someone to fix what is not broken. Each account can now see which provider actually carries its email, texting and calls. Changing it stays with the platform, because repointing where a builder's customer mail leaves from affects domain verification, carrier registration, deliverability and whether replies can come back at all — none of which is visible from the switch.
- Provider state spread across screens reading different tables
- Working channels reported as unconfigured
- Self-serve provider changes with invisible consequences
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 →