Plan channels and deployment

A refund agent that answers every question correctly still has three separate populations to reach: employees who live in Microsoft Teams, customers arriving on a marketing page, and drivers using a field app your own developers ship. The topics, knowledge sources and tools you already know how to build are identical for all three. What changes is the channel, meaning the surface Copilot Studio connects a published agent to. Microsoft's own list of those surfaces covers Teams and Microsoft 365 Copilot, SharePoint, WhatsApp, the demo website, a custom website, a mobile app, Facebook, and Azure Bot Service channels^[1] such as Slack, Telegram, Twilio, Line, Kik, GroupMe, Direct Line Speech and Email.

The enterprise-integration page next door plans the outbound direction, how the agent reaches into other systems. This page plans the inbound direction: which surfaces carry the agent to people, how a release travels to those surfaces, and which client applications are allowed to open a conversation at all. Where the answer turns on choosing and configuring an identity provider, that belongs to the identity-strategy page; what stays here is the part of identity that constrains the channel list itself.

Audience, identity, rendering

Start with where the audience already works, because a channel nobody visits is a channel nobody uses. Employees who spend the day in Teams should not be asked to open a portal, and customers who never sign in to your tenant cannot be served by a Teams-only deployment.

Identity is the second question, and it prunes the list harder than most builders expect. Agents have Authenticate with Microsoft turned on by default, which wires up Microsoft Entra ID authentication without manual configuration; No authentication lets anyone with the link chat with the agent; Authenticate manually configures an identity provider yourself. Microsoft's guidance on this point is not internally consistent, so treat it as something to verify rather than memorise: the authentication article^[2] says in one place that selecting Authenticate with Microsoft gives you the Teams and Microsoft 365 channel and that you can also use native and custom app channels, and in another place that the agent then works only on the Teams channel. The safe planning reading is the one both statements share: Authenticate with Microsoft is built for the Microsoft-hosted surfaces, and if you need authentication on channels beyond them, the article's own advice is to choose Authenticate manually. One consequence is concrete and uncontested: the demo website link appears only when the agent uses No authentication or Authenticate manually.

Rendering is the third question, and it is the one that survives into production as a bug rather than a design note. The channel experience table shows a customer satisfaction survey rendering as an adaptive card, meaning a rich interactive message card, on a website but text only in Teams and Facebook, and Markdown fully supported on a website and only partially in Teams. Teams also renders at most six multiple-choice options (the docs call the same control suggested actions) in one question node, and it does not add citations to a customised generative answers response^[3] the way it does for standard ones. Design the response for the least capable host you have committed to, then let richer hosts render it better.

Answer the three questions in that order and the channel list stops being a menu and becomes a short, defensible set.

The demo website is for teammates and stakeholders while you build; the live website is for customers. Copilot Studio creates a prebuilt demo website when you publish^[4], and Microsoft states plainly that it isn't intended for production use and that you shouldn't share its URL with customers.

That boundary is easy to blur because the demo site is genuinely configurable. You can edit its welcome message and its conversation starters, which are the trigger phrases that launch specific topics, and Microsoft even recommends rewriting the welcome message between test rounds so it tells testers what to try next: store hours this week, gift cards the week after. None of that customisation promotes the site. It stays a feedback surface with a URL you share internally.

The live deployment is a different artifact. You add the agent to your own page with a web chat code snippet whose tokenEndpoint constant you replace with your agent's token endpoint, copied from the channel configuration. The page can be external or internal, a SharePoint site included. The practical difference for planning is ownership: the demo site is hosted for you and has no place to put a credential, while your own page is code your team ships and can therefore hold the server-side pieces the next sections describe.

One more distinction lives at the other end of the build. The Test agent panel inside Copilot Studio is where you check that conversation logic works while authoring; the demo website is where other people try the published agent. Neither one proves how a response renders in Teams, because neither one is Teams.

When the agent has to appear inside software your own developers own, the channel is Mobile app, and it covers two approaches with very different amounts of work. Choose between them before you estimate anything.

The first approach is a web-based app. You copy the code snippet from the Web-based apps section of the Mobile app channel and hand it to your app developers to paste in. Microsoft calls this relatively straightforward, while still noting that both approaches require considerable developer expertise to integrate the agent properly.

The second approach is a native or custom app, and it is an API integration rather than an embed. Direct Line is the piece doing the work here: it is the Bot Framework channel Copilot Studio uses to connect your web page or app to the agent^[5], and the credentials it runs on are the subject of the web channel security section below. Your developers retrieve the agent's name and its Token Endpoint from the Mobile app channel page, GET that endpoint to obtain a Direct Line token^[6], then use the token to start a conversation and to post and receive activities through the Direct Line API; the figure in that later section draws the exchange end to end. The same pattern serves anything with a client and a network stack, including Internet of Things (IoT) devices, which is why Microsoft's article on publishing to mobile or custom apps treats mobile as the common case rather than the only one.

This is not the same decision as adding the agent to your website, even though both end up talking to Direct Line. A website embed is a page you host and a snippet you paste. A native app integration is a client you compile, ship through an app store, and update on its own release schedule, which means a channel change that a website absorbs in one deployment may take an app version to reach every device. Plan the mobile channel as a piece of software with its own lifecycle, not as another place to paste a snippet.

Publishing is a single act with a fanned-out effect: publishing applies to all the channels associated with your agent^[1], and there is no per-channel content publish to run afterwards. That cuts both ways. A fix you publish for the website reaches Teams whether you tested it there or not, and a change you never publish reaches nobody, because customers keep talking to the last published version.

Ordering matters at the start. You must publish before customers can engage with the agent at all, and only after the agent is published at least once can you connect it to more channels. So the first release is always publish, then connect, then publish again after any later change.

Timing matters after that. The latest published content becomes available when a new session starts, which is deliberate: it avoids rewriting the rules underneath someone who is mid-conversation. In most channels a session ends after 30 minutes of inactivity. Channels with persistent conversations, Microsoft Teams and Omnichannel for Customer Service among them, behave differently, because the conversation does not lapse on its own; the figure calls them persistent channels. There you can enter start over to reset the conversation and pick up the newest content immediately, and if you do not, Microsoft's guidance is that it might take an hour after publishing for the latest version to take effect, after which users get the new version on their next message. The figure below traces those outcomes from a single publish.

Write acceptance tests against that model rather than against a stopwatch. "Tester sees the corrected refund text after starting a new conversation" is a check that passes reliably; "tester sees it immediately in an open Teams thread" is a check that fails for a reason that has nothing to do with your agent.

Publishing makes the content current. It does not put the agent in anyone's app list. In Teams and Microsoft 365 Copilot those are two releases, and the second one has three routes with different blast radii and different approvals.

Start with yourself. Microsoft's instruction is to add the agent to your own profile in Teams first, before sharing it with others^[3], and the fundamentals article makes the same point: publish only for yourself, test the published version, then widen. The button that installs it for you sits in the Teams and Microsoft 365 Copilot channel panel, and the two articles label it differently, so navigate to the channel panel rather than hunting for a particular caption.

From there the routes fan out, as the figure below shows. An installation link, copied from Availability options, reaches only users who already have access to the agent, and it cannot be used in the Teams mobile app. The Built with Power Platform section of the Teams app store shows the agent to shared users only, and only while the number of shared users stays inside your tenant's app store discovery policy. The organisation-wide route is Show to everyone in my org, which submits the agent for admin approval so it can be featured in the Built for your org section of the Teams app store, and in the Built by your org section of the Microsoft 365 Agent Store if the agent is also published to Microsoft 365.

Two details about that third route change how you sequence work. Remove the agent from the Built with Power Platform section before you submit it, or it can end up showing in two places. And approval is about the app, not the content: once an agent is approved you can make content updates and publish them as often as you like without resubmitting, while changing the agent's details, such as its icon or descriptions, does require a new approval request.

So the staged sequence is install for yourself, share with a named group, then submit for approval. Submitting first makes an admin your test harness.

By default, a Copilot Studio agent is reachable by anyone who knows its agent ID. Microsoft states it directly: the Demo website and Custom website channels are available by default with no configuration needed^[5], and users can obtain the agent ID from inside Copilot Studio or from someone who has it. For an agent that answers internal pricing questions, that default is the whole problem.

Require secured access, under Settings, Security, Web channel security, is the control that closes it. With the toggle on, channels require the client to authenticate its requests using either a Direct Line secret or a token generated from that secret and obtained at runtime, and attempts that provide neither don't work. Two operational facts belong in the plan, not in the incident review. Turning the setting on or off can take up to two hours to propagate, during which the previous setting is still in effect, and this change does not require publishing the agent. The demo website has no credential of its own to present, which is why Microsoft's own disable confirmation describes turning the setting off as what makes the demo website, and any Direct Line channel not using a secret or token, available again.

The secret is a master key

A Direct Line secret is a master key that can be used to access any conversation belonging to the agent, and secrets don't expire^[7]. A token is a key to a single conversation that expires unless refreshed. That difference dictates where each one may live. For a service-to-service application, sending the secret in the Authorization header is the simplest approach. For anything whose code the customer can read, a browser page or a mobile app, you must exchange the secret for a token in your service, and Microsoft's warning is unambiguous: don't expose the secret in any code that runs in the browser, either hard-coded or transferred through a network call.

The exchange itself is one request. Your service posts to https://directline.botframework.com/v3/directline/tokens/generate with Authorization: Bearer <SECRET>, and the response carries a conversationId, a token valid for one conversation, and expires_in, the number of seconds until that token expires. The figure below traces the four hops, and the shape to keep is that only the last hop crosses into untrusted code.

What secured access does not decide

Require secured access authenticates a client application. The Authentication setting on the same Security page authenticates a person, deciding whether users sign in and which identity variables your topics can read. They are not substitutes and they are not alternatives. A customer portal that only approved hosts may embed, and whose individual employees must each be identified, needs the secured-access toggle for the host and an authentication configuration for the people, which is the split the identity-strategy page develops in full.

Credentials outlive releases, so plan their lifecycle before you hand the first one out. Copilot Studio provides two Direct Line secrets that work simultaneously^[5], which lets you change the secret an agent uses without downtime or interruption.

The order is what makes it non-disruptive, and the figure below lays it out. Move your clients onto the other secret, wait until they are all connected with it, and only then regenerate the one you are retiring. Regenerating is the destructive step: the user profile that connects using the original secret, or a token obtained from that secret, is disconnected. Regenerate first and you have taken the outage you were trying to avoid.

Tokens have their own clock

A token is refreshed, not rotated. It can be refreshed an unlimited number of times as long as it hasn't expired, an expired token can't be refreshed, and the refreshed token is valid for the same conversation as the one it replaces. A long-running conversation therefore needs a client that refreshes ahead of expires_in rather than one that reacts to a failure, because recovering after expiry means going back to your service for a fresh token.

These two lifecycles solve different problems. Rotation is about the credential your organisation holds and answers "this secret may have been exposed". Refresh is about the credential a single user's session holds and answers "this conversation is still going". A rotation does not save a session whose token has expired, and a refresh does nothing about a leaked secret.

One exception is worth knowing before you design a rotation runbook: with a Teams-only licence you can't generate secrets to enable secure access, because secure access tokens are created automatically and secured access is on by default.

Every trap below is a reasonable-looking shortcut past one of the boundaries this page has drawn, and each one has been a real production incident somewhere.

Treating the demo URL as the deployment is the most common. Customising the welcome message makes the demo site a better test surface and nothing more; the live deployment is the snippet on your own page.

Putting Secret 1 in the page's JavaScript is the most expensive. An internal domain does not change what the secret is, and a master key to every conversation on the agent is not a client-side value. The token exchange exists precisely so that browser code holds something scoped and short-lived.

Reading Require secured access as user sign-in inverts two controls that happen to sit on the same Security page. The toggle decides which clients may connect; the Authentication setting decides who the person is. An agent can have a locked-down host full of anonymous users, or an open host full of signed-in ones, so name which problem you are solving before you reach for either.

Submitting to the organisation app store as the first test of a build makes an admin your reviewer and puts a rollback behind someone else's queue. Install for yourself, then share with a named group, then submit.

Assuming the Test agent panel proves rendering fails late and visibly. The panel proves conversation logic. A survey that renders as an adaptive card on your website arrives as text in Teams, so validate the format on each host you actually ship to.

Expecting immediate effect from either propagation path is the quiet one. Both delays are the ones the publishing and web channel security sections measured: content reaches a user's next session rather than an open conversation, and Require secured access takes up to two hours, so a change that looks ignored may just be early. Build both delays into the release plan and neither becomes a surprise.