Channels, Deployment and Audience Design
Plan which channels to deploy agents to, understand channel-specific capabilities, and design different experiences for internal employees vs external customers.
Why channel and audience planning matters
Think of channels as different storefronts for the same business.
A coffee chain sells the same coffee in airports, shopping malls, and drive-throughs. But each location has different rules — the airport shop cannot have outdoor seating, the drive-through does not need chairs at all. Same product, different packaging.
Your agent is the coffee. Channels (Teams, website, Facebook) are the storefronts. Each channel has different capabilities — SSO works in Teams but not on websites, Adaptive Cards render in Teams but not on Facebook. And who your customer is (employee vs external user) changes everything about what the agent should say, show, and access.
Channel capabilities
Each channel has different technical capabilities. Choosing the wrong channel for your scenario means features will silently fail or degrade.
| Feature | SSO | Adaptive Cards | File upload | Proactive messages | Best for |
|---|---|---|---|---|---|
| Teams | Yes | Full support (rich rendering) | Yes | Yes (via Bot Framework) | Internal enterprise agents — richest feature set |
| M365 Copilot | Yes | Supported (Copilot card format) | Limited | No (response-only model) | Extending M365 Copilot with custom agent skills |
| Website (embed) | No | Basic (rendered as HTML fallback) | Yes | No | Customer-facing support, lead capture, FAQ agents |
| Direct Line | No (custom token) | Full (your app controls rendering) | Yes | Yes | Custom apps, mobile apps, kiosks — full API control |
| Facebook Messenger | No | No (text + buttons only) | Yes (images) | Yes (via Facebook API) | Consumer engagement, marketing bots, simple Q&A |
Exam tip: publishing is global
When you publish an agent in Copilot Studio, the update goes live on ALL configured channels simultaneously. There is no way to publish to Teams first and website later in a staged rollout from the Copilot Studio UI. If you need staged deployment, use separate environments (dev/test/prod) with solution promotion — publish in dev first, validate, then promote the solution to production.
Internal vs external audience design
The audience split is not just about authentication — it changes nearly every design decision.
| Feature | Authentication | Data access | Content tone | Compliance | Fallback strategy |
|---|---|---|---|---|---|
| Internal (employees) | SSO via Entra ID (Teams/M365) | Full enterprise data with delegated permissions | Professional, can reference internal systems by name | Internal data governance, DLP policies apply | Escalate to internal support team or service desk |
| External (customers/partners) | Manual OAuth or no auth | Limited — public data or customer-specific scoped data only | Brand-aligned, no internal jargon, accessibility-first | GDPR/privacy regulations, data residency, consent tracking | Escalate to customer support queue or create support ticket |
Key design differences to remember:
- Error messages: Internal agents can say “Check the ServiceNow ticket in ITSM portal.” External agents should never reference internal systems.
- Fallback behaviour: Internal agents escalate to a Teams channel or service desk. External agents create a support ticket or offer a callback.
- Data exposure: Internal agents can surface employee directories, org charts, internal KB articles. External agents must never leak internal data — even in error messages.
- Conversation history: Internal conversations may be retained for compliance. External conversations may require explicit consent and data retention policies.
Scenario: Priya designs internal + external recruitment agents
Priya’s AgentForge client — a recruitment firm — needs two agents:
Internal: Recruiter Assistant (Teams)
- Audience: 50 internal recruiters
- Auth: SSO with delegated permissions
- Features: Search all candidates in the ATS, view hiring pipeline, schedule interviews via Graph Calendar API, rich Adaptive Cards with candidate profiles
- Fallback: Escalate to #hiring-ops Teams channel
- Tone: Direct, can reference “ATS,” “pipeline stages,” internal terminology
External: Candidate Portal Agent (website)
- Audience: Job applicants visiting the careers page
- Auth: No authentication (general Q&A) + manual OAuth for application status checks
- Features: Answer FAQ about open roles, check application status (authenticated), submit interest forms
- Fallback: “We will have a recruiter reach out within 24 hours” + create ticket
- Tone: Warm, brand-aligned, no internal jargon, accessibility-compliant
Same data platform, completely different agent design. Priya builds both from a shared solution but customises topics, auth, and tone for each audience.
Multi-channel deployment strategy
Most enterprise agents need to work across multiple channels. Planning the multi-channel strategy avoids surprises:
- Design for the lowest common denominator first — if your agent runs on Facebook and Teams, build the core experience with text + buttons (Facebook’s limit). Then enhance with Adaptive Cards for Teams using channel-specific conditions.
- Use channel detection in topics — the
System.Channelvariable tells you which channel the conversation is on. Use it to conditionally render rich cards in Teams and plain text elsewhere. - Test on every target channel — Adaptive Cards that look great in Teams may render as JSON blobs on channels that do not support them. Always test.
- Plan authentication per channel — SSO for Teams, manual OAuth for website, no auth for Facebook. Each requires different topic flows.
// Conceptual topic logic for multi-channel adaptive rendering
if (System.Channel === "msteams") {
// Send rich Adaptive Card with candidate profile
sendAdaptiveCard(candidateCard);
} else {
// Send plain text summary for channels without card support
sendMessage(`Candidate: ${name}\nStatus: ${status}\nNext step: ${action}`);
}Direct Line: the developer's channel
Direct Line is the most flexible channel because it is essentially a raw API. Your custom application handles rendering, auth, and UX — Copilot Studio provides the conversation engine. Use Direct Line for mobile apps, kiosk interfaces, custom web experiences, or any scenario where the prebuilt channels are too restrictive. The trade-off is that you build and maintain the client yourself.
Priya's recruitment agent needs to display candidate profiles with photos, action buttons, and structured data in Teams, but the same agent also runs on the company website. What should she do?
An enterprise agent is deployed to Teams (internal) and a public website (external). A customer on the website asks about internal pricing tiers. What should the agent do?
Dev needs to build an agent for a logistics company's warehouse kiosks. The kiosks run a custom Android app. Which channel should he use?