2.3 Plan Channels and Deployment

2.3 Plan Channels and Deployment

Quick Answer: Publish before any user-facing channel works. Connect channels such as Teams and Microsoft 365 Copilot, custom/demo website, SharePoint, mobile, and Azure Bot Service endpoints based on audience. Use dev/test/prod Power Platform environments and gradual audience targeting—never treat the Test pane as production validation.

Channels are the surfaces where people chat with your agent. Deployment is how a version moves from maker experimentation to controlled production audiences. AB-620 planning questions mix both: the right channel for an audience, the right publish/share path, and the environment strategy that keeps LOB integrations safe.

Publish fundamentals

1. Build and test in the Test agent pane (maker experience).
2. Publish to push the latest content to connected channels.
3. Add or configure channels after at least one successful publish.
4. Publish again after content, auth, or channel-related changes.

Publishing applies across all channels linked to that agent. If you change topics but forget to publish, users keep the old experience. To reduce mid-conversation disruption, new published content typically applies on a new session. On persistent channels (Teams, some customer service channels), users may need start over or wait for session refresh behavior documented for that channel.

Demo website vs production web

Exam tip: demo website is not your production channel plan.

Primary channels to plan

Teams and Microsoft 365 Copilot

For internal employee agents, Teams + Microsoft 365 Copilot is the default enterprise destination. After publish:

• Connect the Teams and Microsoft 365 Copilot channel
• Install for yourself first (Open the agent in Teams)
• Then make available to others through sharing / admin deployment paths

Benefits:

• Users stay inside daily Microsoft 365 work surfaces (Teams, Copilot Chat, related entry points)
• Authenticate with Microsoft aligns cleanly
• Org governance via sharing, Teams app policies, and M365 admin controls

Deployment paths commonly discussed in the field:

Plan with Microsoft 365 and Teams admins early if you need auto-install, pinning, or blocked sideloading in non-prod environments.

Web and custom channels

Use web embedding when:

• External customers visit a public site
• Employees use a custom intranet portal outside Teams
• You need a branded canvas (Web Chat / custom UI)

Custom website supports richer control (and SSO with manual Entra auth). Remember channel experience differences—markdown, suggested actions, surveys, and welcome messages do not behave identically on web vs Teams vs Facebook.

SharePoint

SharePoint as a channel hosts the agent where content lives—useful for departmental sites. Combine carefully with SharePoint as a knowledge source: channel placement ≠ automatic knowledge configuration.

Mobile apps and Azure Bot Service channels

Mobile app and Azure Bot Service channels (Slack, Telegram, Twilio, Line, email, Direct Line variants, and others) extend reach. Plan them only when the audience truly lives there. Auth and SSO support differ—several ABS channels do not support SSO.

Omnichannel / customer service handoff

When the agent is part of a contact center journey, plan Dynamics 365 Customer Service / Omnichannel handoff constraints (including authentication option limitations called out in docs).

Channel experience constraints (design impacts)

On the exam, if a scenario emphasizes rich adaptive cards and long choice lists for Teams, prefer simplifying the interaction model or choosing a channel that supports the UX.

Environment strategy (dev / test / prod)

Copilot Studio agents live in Power Platform environments. Treat them like any enterprise Power Platform workload:

Why this matters for channel planning:

• A dev agent accidentally connected to production ServiceNow with maker credentials is an incident waiting to happen
• Teams deployment of a half-finished agent creates support load
• Connection references and environment variables (later ALM skills) depend on multi-environment design

Practical controls used with non-prod:

• Do not connect production Teams channel to dev agents
• Use Teams admin setup policies to block custom app upload where required
• Disconnect Teams channel on dev agents if makers could otherwise sideload broadly
• Point connectors at sandbox ServiceNow/SAP instances in lower environments

Audience targeting and release rings

Think in rings:

1. Maker only — Test pane + personal Teams install
2. Project stakeholders — demo website or limited share
3. Pilot group — security group share / limited M365 availability
4. Organization — admin deployment, store visibility, pinning

Agent sharing (who can chat) interacts with authentication:

• No authentication → cannot meaningfully gate to named org users via sharing
• Authenticate with Microsoft → sharing controls org audience on Microsoft channels
• Manual Entra with require sign-in → stronger control than generic OAuth2 public clients

Also decide internal vs external audience at planning time (a related blueprint skill). External web often implies different voice, branding, auth, and data boundaries than an employee Teams agent—even if both call the same ServiceNow instance.

End-to-end deployment plan template

1. Audience & channel shortlist — employees in Teams/M365, customers on web, or both (possibly two agents or multi-agent).
2. Auth mode per channel set — Microsoft auth for M365-only; manual Entra for authenticated web+Teams; no auth only if public and safe.
3. Environment topology — dev/test/prod with solution packaging path (detailed in Domain 3 ALM).
4. Integration endpoints per environment — sandboxes vs production LOB.
5. Publish checklist — content, knowledge, tools, auth, channel config.
6. Validation — Test pane, then published channel smoke tests (SSO, knowledge ACL, ticket create).
7. Rollout — pilot share → admin deploy → monitor failures and republish.

Exam scenarios to rehearse

Scenario A: Contoso wants an IT help agent for all employees inside Teams and Microsoft 365 Copilot next quarter.
Plan: Build in dev, UAT in test with ServiceNow sandbox, Authenticate with Microsoft, publish, connect Teams/M365 channel, pilot with IT, then admin-led org deployment.

Scenario B: Marketing wants the same agent on the public website for anonymous product questions.
Plan: Do not blindly reuse the employee agent with SharePoint HR knowledge. Prefer a separate public agent/channel strategy with public knowledge only, or a carefully segmented multi-agent design.

Scenario C: Stakeholders love the Test pane demo; leadership asks to “turn it on for the company tomorrow.”
Plan: Refuse big-bang. Publish, limited share, channel-specific tests, then staged admin deployment.

Scenario D: Maker updated topics this morning; Teams users still see old dialogs.
Plan: Confirm publish succeeded; start a new session (start over where applicable); account for session refresh timing on persistent channels.

Channel & deployment checklist

• Target audiences listed (internal, external, both)
• Channels selected with UX constraints reviewed
• Authentication compatible with every selected channel
• Dev/test/prod environments and LOB sandboxes defined
• Publish process and session refresh behavior understood
• Audience rings and admin deployment path agreed
• Monitoring owner assigned for post-publish failures

When integration (2.1), identity (2.2), and channels/deployment (2.3) are planned together, Copilot Studio agents ship as governed enterprise products—not as one-off chat experiments.