Channels, Deployment and Audience Design

Why channel and audience planning matters

Channel capabilities

Each channel has different technical capabilities. Choosing the wrong channel for your scenario means features will silently fail or degrade.

Channel capabilities comparison — features vary significantly across channels

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.

Internal vs external agent design — every layer changes based on audience

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:

1. 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.
2. Use channel detection in topics — the System.Channel variable tells you which channel the conversation is on. Use it to conditionally render rich cards in Teams and plain text elsewhere.
3. 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.
4. 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.

Question

What happens when you publish an agent in Copilot Studio?

Click or press Enter to reveal answer

Answer

The update goes live on ALL configured channels simultaneously. There is no per-channel staged rollout from the UI. Use separate environments (dev/test/prod) with solution promotion for staged deployment.

Click to flip back

Question

Which system variable identifies the current channel in a topic?

Click or press Enter to reveal answer

Answer

System.Channel — use it in conditions to branch logic per channel (e.g., send Adaptive Cards in Teams, plain text on Facebook).

Click to flip back

Question

Name three design differences between internal and external agents.

Click or press Enter to reveal answer

Answer

(1) Auth: SSO for internal, manual OAuth or none for external. (2) Data: full enterprise access vs scoped/public only. (3) Fallback: escalate to internal team vs create support ticket. Also: tone, error messages, and compliance requirements differ.

Click to flip back

Knowledge Check

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?

ABuild two separate agents — one for Teams and one for the websiteBUse Adaptive Cards everywhere — they work on all channelsCDesign a base text experience, then conditionally add Adaptive Cards when System.Channel is TeamsDOnly deploy to Teams and drop the website channel

Check Answer

Knowledge Check

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?

AShow the internal pricing document — the customer asked for itBRedirect to the Teams version where internal docs are accessibleCRespond with publicly available pricing information and offer to connect with salesDAsk the customer to authenticate to access internal data

Check Answer

Knowledge Check

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?

ATeams — richest feature setBWebsite embed — works in any browserCDirect Line — full API control for custom appsDFacebook Messenger — easy to set up

Check Answer

🎬 Video coming soon

Channels, Deployment and Audience Design