Copilot Studio Agents That Break Outside the Test Canvas

Why does an agent work in the test canvas and fail once it is published?

Because the test canvas and a published channel are two different runtime situations that happen to share a topic editor. In the test pane the conversation runs inside your authoring session: you are signed in, connections you created while building are available, and the draft you are editing is what answers. In Teams, Microsoft 365 Copilot or a website, the conversation belongs to an end user, or to no user at all, the agent uses whatever was last published, and every connector, flow, knowledge source and HTTP call has to authenticate as someone other than you.

So "works in test" mostly proves that the logic of the topics is right and that you personally hold the access they need. Work through the causes below in order. Before you start, spend thirty seconds on the cheapest check of all: publish again, then start a fresh conversation in the channel, as the section on publishing explains. What a Copilot Studio build covers end to end, including grounding, handoff and measurement, is on our Copilot Studio agent development page and is not repeated here.

Is the authentication setting the same one the channel actually uses?

Copilot Studio agents have an agent level authentication setting, which at the time of writing offers three broad choices: no authentication, authenticate with Microsoft, and authenticate manually with an identity provider you configure. The names and the page they live on have changed more than once, so check current Microsoft documentation for your tenant, but the behaviour behind the three choices is what matters.

With no authentication, the agent does not know who the user is, so anything that needs a user identity, such as knowledge sources and tools that run with the end user's credentials, cannot work for real users even though it worked for you in test. With authenticate with Microsoft, sign-in is handled for Microsoft channels such as Teams and Microsoft 365 Copilot, and the agent is typically limited to those channels, so a website or custom channel will not behave the same way. With manual authentication, the agent uses an app registration and scopes you supply, and a mistake in the client ID, secret, redirect URL or scopes shows up only when a real user tries to sign in.

• Confirm which option is set in the published version, not only in the draft. Authentication changes need a publish to take effect.
• Confirm the channel you deployed to is supported by that option. A website embed and Teams do not have the same sign-in behaviour.
• Test in the channel as a second account that is not a maker of the agent, with no connections of its own, in a private browser window or a separate Teams profile.
• Check who is allowed to use the agent. Access can be restricted to specific users or security groups, and a user outside them sees an access message that looks like a failure.
• For manual authentication, check the redirect URL registered on the app registration matches what Copilot Studio requires, and that the scopes include what the downstream calls need.

Whose identity reaches Dataverse once the agent is published?

Until you can answer this for each failing step, every other fix is guesswork. A published agent can reach Dataverse through several routes, and each one runs as a different identity.

• Dataverse knowledge sources and similar grounded answers generally run as the signed-in end user, so a user sees only what their own security roles allow. An empty or evasive answer for users that was full for you is usually their roles, not the agent.
• Connector tools can be configured to use the end user's credentials or credentials the maker provided. End user credentials mean each user needs access and a connection of their own. Maker provided credentials mean every user acts through one shared connection, which works for everyone and is also a security decision you should make deliberately.
• Agent flows and Power Automate flows called as tools run with the connections embedded in the flow or bound through its connection references, not as the chatting user. Our Power Automate service page covers service accounts, service principals and connection references for that side.
• HTTP calls from a topic, or a custom backend, run as whatever that call authenticates with: the user token from manual authentication, or an app registration using a client secret or certificate.
• An app registration reaching Dataverse needs a matching application user in that specific environment, which is the next check.

Does the application user exist in this environment with the right security role?

When a flow connection, a custom connector or a backend service reaches Dataverse as an app registration, Dataverse only recognises it through an application user created in that environment and linked to the app registration's client ID. Application users do not travel with a solution. The one created in development does not exist in test or production until someone creates it there, which is one of the most common reasons an agent works in development and fails everywhere else.

• In the Power Platform admin center, open the target environment, find the application users list under the environment settings for users and permissions, and confirm an application user exists for the exact client ID the failing call uses.
• Confirm it has a security role assigned in the right business unit. An application user with no role authenticates successfully and then fails every data operation.
• Grant a least privilege custom role covering exactly the tables and operations the agent needs, rather than System Administrator. The role design itself is covered in our guide to Dynamics 365 security with business units and teams.
• Check column security. If the agent reads or writes secured columns, the application user needs a column security profile that allows it.
• Check the application user is enabled and that the app registration has not been replaced by a new one with a different client ID.

Has a client secret on the app registration expired?

If the agent worked for weeks and then failed for everyone at once, look at the app registration before anything else. Client secrets are created with an expiry date, and when one expires every sign-in that uses it fails. Entra ID reports this with a specific error, AADSTS7000222, stating that the client secret keys have expired, which you will see in the service principal sign-in logs or in the error returned to the connector, flow or backend.

The same failure hides in several places: the manual authentication configuration of the agent itself, a custom connector's OAuth settings, a Dataverse connection authenticated as a service principal, and any backend service your topics call. Each may use a different app registration, and development may use a different one again, which is how one environment breaks while another keeps working.

• Open Certificates and secrets on each app registration the agent depends on and read the expiry dates.
• Create a new secret, update every place that stores it, then remove the old one once calls succeed.
• Prefer certificates or a managed identity for backend services where the component supports them, and keep secrets in Azure Key Vault rather than pasted into configuration.
• Put expiry dates in a register with an owner and an alert well before the date, because the failure is entirely predictable.

Are conditional access or data policies blocking the connectors?

Two different policy layers block published agents, and neither applies to you in the way it applies to your users. Conditional access in Microsoft Entra ID decides whether a sign-in is allowed at all, based on things like device compliance, location, sign-in risk and the application being accessed. A maker testing from a compliant laptop on the corporate network passes. A user on a personal phone in Teams may be blocked, and the connector or sign-in step simply fails in the conversation. Entra ID records this as a sign-in failure with the conditional access result, commonly error AADSTS53003, and the policy that applied.

Data policies in Power Platform, often called DLP policies, decide which connectors can be used together in an environment, and some also govern Copilot Studio channels, knowledge sources and authentication options. Development environments are frequently excluded from the strict tenant policy, while production is not. The result is an agent that was built and tested freely, then fails to publish, loses a tool, or errors at runtime in production. Exact connector names for Copilot Studio capabilities change, so compare the policies on both environments in the admin center rather than relying on a list.

• Open the Entra ID sign-in logs for a failing user at the time of failure, including non-interactive and service principal sign-ins, and read the conditional access tab.
• Compare the data policies applied to the development and production environments, connector by connector, including any that govern Copilot Studio channels and knowledge.
• Fix policies with the tenant administrators rather than around them. An exception for a specific connector in a specific environment is a normal governance decision; a shared account that avoids conditional access is not.

How should per-user tokens for external APIs be handled safely?

When the agent calls APIs outside Microsoft on behalf of each user, the token belongs to that user and must never become shared state. The common mistake is to obtain a token once, put it in a global variable, pass it through a flow as a plain input, or echo it into a message while debugging. Variables can be visible in conversation transcripts and analytics, flow inputs and outputs are visible in run history unless secured, and a shared variable can hand one user's access to another. A token that works in test, because it is yours, becomes a data exposure once published.

There are two safe patterns, and which fits depends on how many APIs you call. For a few APIs with OAuth support, use a custom connector configured for OAuth with the tool set to use end user credentials: each user consents once and the platform stores and refreshes the connection for them, so the agent never holds a raw token. For many APIs, or APIs with their own credentials per user, put a backend in front of them: an API service or Azure Function that the agent calls with the signed-in user's Entra ID token, which validates that token, exchanges it for downstream tokens using the on-behalf-of flow where the API trusts Entra ID, and keeps any per-user refresh tokens or API keys in Azure Key Vault or an encrypted store keyed by the user's object ID. The agent passes intent and parameters; the backend holds credentials.

• Never store tokens in agent variables, global variables, adaptive card data or messages, and never log them.
• Mark inputs and outputs as secure on any flow action that handles a token or secret, so run history does not show the value.
• Scope each token to the least the API needs, and let the backend check the user is allowed to perform the action rather than trusting the agent.
• Handle expiry and revocation. When a refresh fails, ask the user to sign in again rather than falling back to a shared credential.
• Record which user triggered which external call in the backend log, which is also the audit evidence discussed in our guide to governing Copilot and AI agents over Dynamics 365 data.

Has the latest version actually been published to the channel?

The test canvas runs your draft. Channels run the last published version. Topic edits, tool changes, knowledge sources and the authentication setting reach users only after Publish, and it is easy to fix something in test, see it work, and forget. In Teams, an existing conversation can also keep behaving as before for a while, and the app itself may be cached by the client.

When an agent moves between environments through a solution, publishing is only half of it. Connection references and environment variables must be bound in the target environment, authentication settings may need to be configured there, and the agent needs publishing in that environment too. The solution promotion discipline behind that is set out in our Power Platform ALM guide.

• Check the publish history or last published time on the agent against the time of your fix.
• Start a new conversation in the channel. In most channels typing "start over" resets the conversation, and in Teams closing and reopening the app or restarting the client clears stale state.
• If the Teams app was submitted to your organisation app catalogue, check whether the change needs the app to be resubmitted or approved again by an administrator.
• After promotion, open the agent in the target environment and confirm its connections, environment variables and authentication settings before publishing there.

How do you verify the published agent's identity has the Dataverse privileges it needs?

Prove it from evidence rather than by reading role names. Role names are misleading, business units change what a role grants, and column security sits on top of both. The checks below work whether the identity is an end user, a shared maker connection or an application user.

• Identify the identity from the failing run. Flow run history shows the connection used by each action, Entra ID sign-in logs show which user or service principal authenticated, and a Dataverse error body usually names the missing privilege and table.
• For an end user, sign in to the model-driven app as a test user with the same roles and try the same read or write by hand. Where available, the check access feature on a record shows what a named user can do with it.
• For an application user, call the Dataverse Web API with the same app registration from a tool such as Postman or a short script: first WhoAmI to confirm which user Dataverse sees, then the exact query or update the agent makes.
• Temporarily add a diagnostic topic available only to testers that shows the signed-in user's identity as the agent sees it, so you can confirm authentication is producing the user you expect. Remove it before wider rollout.
• Where auditing is enabled on the table, write a test record through the agent and read the audit history to see which user Dataverse recorded as making the change.
• Fix the role, not the agent. Once the missing privilege is known, add it to the least privilege role and rerun the same call before retesting in the channel.

When is a Copilot Studio agent the wrong tool for the job?

Sometimes the deployment failure exposes a design that was never going to work well as a conversation. If users mainly fill in structured data, a Power App is usually better. If the process must be fully deterministic with no conversational step, an automated flow is. If the agent exists to pull data from many systems, the integration is the real project and deserves its own design. These trade-offs are covered on our Copilot Studio and Power Automate service pages.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. Where Microsoft licensing does not fit the organisation, or the assistant has to live inside a product you own, a custom-built CRM or application on React, Node.js, PostgreSQL and .NET is the alternative.

How does Solzet help when a Copilot Studio agent fails after publishing?

Our senior consultants and full-stack developers deliver remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for end clients or white-label for Microsoft partners. For an agent that breaks once published, we work through the order on this page with your tenant administrators: map every identity the agent uses, read the sign-in logs and run histories, check application users, roles, secrets and policies in each environment, and put per-user token handling on a safe footing. You receive the fix, a short record of each identity and its privileges, and the checks to run before the next release.