# Configuring a channel, end to end

Every channel is configured the same way: prove who you are to the provider, give Connect credentials it seals immediately, route the address or number to one workspace, set the autonomy rule, then verify with real traffic. What differs is who grants the identity and what they can refuse. Following that order makes a channel that does not work diagnosable in one pass.

- **Status:** Available
- **Audience:** both
- **Channels:** email, whatsapp, sms, phone
- **In the app:** #/mailboxes, #/whatsapp-setup, #/calls, #/autonomy, #/dlt
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/channel-configuration/

## The chain

1. Trigger — a workspace decides to add a channel, or to replace the provider behind one it already has.
2. User event — somebody with permission opens the channel's screen: Mailboxes for email, the WhatsApp setup route, Phone for voice and SMS readiness.
3. Authentication and workspace resolution — the person's session determines the workspace being configured. A customer session reaches these screens through the tenant facade; the Owner reaches them directly, over the same implementation.
4. Request — credentials or an authorisation grant are supplied. For Gmail this is a Google OAuth consent with named scopes; for IMAP or SMTP a host and account; for WhatsApp and SMS a provider's credentials.
5. Canonical record — the credential is sealed by the settings store on save and never echoed back to any screen. What you see afterwards is that a credential exists, not what it is.
6. Classification — the channel's identity is bound to the workspace: a mailbox with a role, a business number, a line. Routing decides which workspace an inbound event belongs to, and it must resolve to exactly one.
7. Knowledge and rules — signature, business hours, standing instructions and any channel-specific constraints are set here rather than left to the model to infer.
8. Autonomy — the rule for this channel is chosen in What Connect May Do: `off`, `draft_only`, `ask_before_send` or `autonomous`, at whichever scope is right. The narrowest applicable scope wins.
9. Action — the first real event proves the configuration. Nothing about a channel is verified by the absence of an error on a settings screen.
10. Result — health is reported: a connected mailbox that is fetching, a line that is ready, or a readiness message naming what is missing. A `foundation` channel says so here rather than presenting a compose box.
11. Relationship and memory — inbound events start attaching to People immediately, and the channel becomes one more identity type on records that already exist.
12. Audit and usage — the configuration change is recorded with who made it, and traffic begins counting against a customer workspace's allowances.
13. Next — verification proper, which is its own workflow: [Verifying a channel actually works](/docs/workflows/channel-verification/).

## Where the four channels differ

| Channel | Who grants the identity | What can refuse you | Status |
|---|---|---|---|
| Email | Google, Microsoft, or your own IMAP/SMTP host | OAuth scopes, a host that rejects the credential, a mailbox that will not sync | Available |
| WhatsApp | A WhatsApp Business provider | Template approval, session-window rules, media and delivery reporting limits | Available |
| Phone | A carrier for the PSTN leg | Number verification, carrier capability, line readiness | Available |
| SMS | Whichever provider carries the number | The carrier itself — the live one carries no SMS — and in India, DLT registration | Foundation |

The last row is the reason this page is worth reading before configuring anything. Three of the four channels end in a working two-way channel; the fourth ends in a working inbound channel and an honest readiness message. Configuration cannot change that, and a setup that appears to succeed does not mean text will send.

## The rules that hold for all of them

- **A credential is sealed on save.** No screen displays it again, and no support conversation should ever ask you to paste one back.
- **Routing must be unambiguous.** An inbound event resolves to exactly one workspace; anything that does not is a dead letter rather than a message filed somewhere plausible.
- **Autonomy is set per channel, and the narrowest scope wins** — one contact overrides one endpoint, which overrides the channel, which overrides the workspace.
- **Suppression is shared, not per channel.** A do-not-contact entry recorded against a contact governs the new channel from the moment it exists.
- **Nothing is verified by configuration alone.** A saved setting proves somebody typed something; only traffic proves a channel.

> **Note** Configure the autonomy rule before the first real message rather than after. A channel switched on at `autonomous` because nobody chose otherwise will act on the first thing it receives, which is rarely what a workspace intends on day one.

## Questions

### Can one workspace have two providers on the same channel?

Credentials are held per workspace and per channel identity, so several mailboxes or several numbers can coexist, each with its own role and its own autonomy. What they share is the canonical record they all write into, which is why adding one does not change how anything downstream behaves.

### Does configuring SMS achieve anything today?

Recording DLT registrations and letting inbound text attach to people does. Enabling outbound does not, because the live carrier carries no SMS — the readiness on the Phone screen says which condition is unmet rather than offering a compose box that would fail.

### Who is allowed to configure a channel?

A workspace member with permission for that channel, and the change is recorded with their name. The Assistant can read settings but its rights are deliberately narrower than a person's for anything that changes how the business reaches customers.

## Related

- [Verifying a channel actually works](https://connectbyjbrh.com/docs/workflows/channel-verification/)
- [A channel provider going down](https://connectbyjbrh.com/docs/workflows/channel-failure/)
- [Setting up WhatsApp](https://connectbyjbrh.com/docs/whatsapp/channel-setup/)
- [Sending SMS: what is available today](https://connectbyjbrh.com/docs/sms/sms-outbound-status/)
- [Mailboxes](https://connectbyjbrh.com/docs/email/mailboxes/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §1, §2 and §3 — email, WhatsApp and SMS
- `docs-source/sources/GENERAL.md` §4, §5 and §10 — screens, autonomy, sealed credentials
- Connect capability registry (docs-source/facts.py) — the `CHANNELS` table