Copilot Studio: Publish and Share an Agent Safely
Publishing a Copilot Studio agent involves testing, configuring the audience, managing updates, and knowing how to withdraw it if needed. Here is how to move through each stage without skipping the checks that protect your users.
Updated 5 min read
Publishing a Copilot Studio agent means moving it from the authoring canvas to a channel where real users can interact with it. That step involves more than clicking a button: the agent needs to be tested with realistic inputs, the audience needs to be scoped, and the people responsible for maintaining it need to understand what they have committed to.
Each release decision, the audience scope, the reviewer assignments, and the conditions under which the agent would be withdrawn, is worth recording before the agent goes live. Tools like fenbs keep those records alongside the agent's development tasks so the whole team works from the same picture when a problem arises.
Test before you publish
The built-in test chat in Copilot Studio is a starting point, not a final check. Before you publish, run the agent through at least three categories of input: the intended happy path, an edge case the agent should handle gracefully, and an input that is clearly outside scope to verify the fallback works.
Ask one or two people who were not involved in building it to try it with their own words. They will ask things the builder did not anticipate. Any input that produces a wrong answer, an error, or a fallback response that is unhelpful is a candidate for a fix before publishing. Keep a list of what was tested and what the outcomes were.
Configure the audience and channel
Copilot Studio publishes to channels: Microsoft Teams, SharePoint, a website as an embedded web chat, Dynamics 365, and others. Each channel has its own configuration. For Teams, the agent becomes a Teams app that users install or that administrators pre-install for a specific group. For a website, you embed a snippet of code that loads the chat.
Scope the initial release to a small audience: a single team, a pilot group, or a specific SharePoint site. A small audience limits the impact of any problem that surfaces after publishing and gives you a feedback group whose experience you can observe closely.
In Teams, pre-installing the app for a specific group through the admin center is cleaner than asking users to install it themselves. It also lets you remove it centrally if you need to withdraw it. For a website embed, control who can reach the page the chat is embedded on.
Assign reviewers and communication paths
Before the first real user opens the agent, decide who is responsible for each type of problem. A wrong answer from a knowledge source needs someone who can update the knowledge source. A flow that fails needs someone who can fix the Power Automate flow. A question that produces an unhelpful fallback needs someone who can add a topic.
Decide also how users report problems. A Teams channel, an email address, or a feedback form in the agent itself are common options. If there is no feedback path, problems accumulate in the agent's analytics without anyone taking action.
Record release decisions and reviewer assignments in fenbs
Add a task for the release to fenbs. Record who reviewed it, what was tested, which audience it was published to, and who is responsible for each problem type. When a user reports an issue after launch, the record shows who to notify and what they are accountable for, without a search through meeting notes.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Update the agent without breaking it
After the initial release, updates are common. A knowledge source changes, a topic needs a new trigger phrase, or a flow is updated. In Copilot Studio, changes to the assistant do not go live until you publish again. Use that publication step as a checkpoint: test the changed area and at least one unchanged area before clicking publish.
Coordinate updates that touch both Copilot Studio and a dependent Power Automate flow carefully. Changing the data a topic sends to a flow without updating the flow at the same time will break the integration. Publish both on the same day, and test the end-to-end path after both are live.
How to withdraw or unpublish an agent
If an agent produces a significant wrong answer, triggers a compliance concern, or encounters a data problem, you may need to withdraw it quickly. In Teams, an admin can remove the app for all users through the Teams admin center. For a website embed, removing or hiding the page removes user access.
You can also disable specific topics or the generative AI feature while leaving the rest of the agent running. That allows a partial withdrawal: the agent continues to handle the topics that are working while you fix the one that is not. Disabling a topic does not remove it; it routes any matching input to the fallback.
How to do this with fenbs
Use fenbs to track the release process from final testing to withdrawal conditions.
- Create a free account and add a project for the agent.
- Add a pre-publication checklist as a task: what was tested, who reviewed it, and which audience it will go to first.
- Record the audience and channel decision as a Decision in fenbs. Include the pilot scope and the criteria for expanding to the full audience.
- Assign each problem type to a named reviewer. Add those assignments as tasks so each person has accepted responsibility before the agent goes live.
- Write a withdrawal condition as a Decision: what kind of problem would trigger an immediate withdrawal, who makes that call, and which admin can remove the agent from Teams or the website.
fenbs does not connect to Copilot Studio's publishing workflow or analytics. Use the Copilot Studio analytics dashboard to monitor topic resolution rates and user satisfaction after launch. fenbs keeps the release decisions and the reviewer record in one place the whole team can access.