Integration reference: connections, channels and capabilities

Separate the account from its destination

An External Connection represents the external identity and its authorization lifecycle. A Channel represents the destination and configured capabilities that use that identity. Provider configuration supplies the service settings behind the connection. This separation allows the workspace to report an authorization problem independently from a destination or delivery problem.

When setting up an integration, record the task you need: publish content, receive a message, send a reply or deliver a mailing list. Do not decide solely from the provider’s name or icon.

Choose the appropriate email connection

Modern email options include Microsoft 365 delegated or shared mailboxes, Microsoft application mailboxes, Gmail OAuth and password or app-password IMAP/SMTP mailboxes. Their authorization, synchronization and provider requirements differ. A shared Microsoft mailbox, for example, can use a different synchronization approach from an owner mailbox.

Legacy outbound SMTP or SendGrid publishing compatibility is not the same as a synchronized support mailbox. Follow email connections when you need incoming messages and Ticket replies, and email mailing lists when you need recipient delivery through Posts.

Check publishing and conversation capabilities separately

Connection-backed social and messaging paths include Telegram Bot, Telegram User, WhatsApp Cloud API, Facebook Page publishing and Instagram professional-account publishing. The exact setup and readiness conditions vary. Telegram User has additional deployment and acceptance requirements.

Facebook and Instagram publishing support must not be interpreted as complete direct-message, comment or mention handling. The wider catalog contains additional provider families with varying implementation depth. Read social connection guidance and verify the current supported operation for the target environment.

Treat email and SMS lists as recipient workflows

Email and SMS mailing lists use configured recipients, post composition, approval where required, scheduling and delivery outcomes. SMS support in this documented path is specifically the configured 019SMS short-text integration; it is not a promise of generic MMS or unlimited multipart messaging.

Lists have their own import and recipient-state rules. Do not assume that a support Contact automatically joins a mailing list, that importing an address establishes marketing consent, or that a successful post status proves every recipient received the message. See the dedicated SMS list guide for its current content limits.

Use a capability checklist before rollout

1. Confirm the required account type and authorization method.
2. Confirm that the exact runtime operation is supported.
3. Check deployment prerequisites and the connection’s authorization status.
4. Configure the channel, destination and any support Department.
5. Test one permitted action and inspect the destination or recipient outcome.
6. Test reauthorization, an unavailable provider or another relevant recovery path.

Keep source availability and live acceptance separate. Documentation of an implementation describes how it is intended to work; the real provider account and deployed configuration determine whether your team can use it now.

Find the layer responsible for an integration problem

Authorization or account-selection problems begin in External Connections. Destination configuration, synchronization and provider delivery belong with Channels. Ticket routing and staff access belong with Tickets. Conversation presentation belongs with the configured conversation surface. Post editing and approval belong with Publishing and Lifecycle.

This map also applies to website AI agents: an agent conversation, a Ticket tool and a staff handoff each require their own working connection. Check the failing operation rather than reconnecting unrelated services.