Microsoft Copilot Not Working, Delegation, Flow, and Data Source Fixes
Why Microsoft Copilot Is Not Working
I've been on support calls where someone spent an entire afternoon staring at a blank Test panel, their Copilot Studio agent just sat there, completely silent, like it forgot it had a job to do. No error. No response. Nothing. And the worst part? The Microsoft error messages, when they do appear, are so vague they might as well say "something is wrong, good luck."
Here's the thing: when Microsoft Copilot is not working, it's almost never a single cause. You're dealing with a product that sits at the intersection of Power Platform connectors, Azure infrastructure, SharePoint permissions, organizational policies, and real-time WebSocket connections, and any one of those layers can quietly break things without giving you a useful message.
The most common failure patterns I see fall into four buckets. First, connector delegation failures, where your agent tries to call a service like ServiceNow or SharePoint and gets back an HTTP 400 Bad Request because the response payload is too large. Microsoft Copilot Studio has a hard 500 KB limit on connector responses. If your query returns more than that, the whole action fails and the agent goes silent or throws a cryptic error. Most users never realize this is the ceiling they're hitting.
Second, data source and knowledge configuration issues, generative answers that point to SharePoint not returning results, Bing-based sources blocking agent publishing, and enterprise knowledge sources that look configured correctly but produce nothing. These break in ways that are particularly maddening because everything looks right in the Copilot Studio UI.
Third, administrative policy blocks, someone in your IT department disabled AI prompts at the environment level in Power Platform admin center, or your organization's firewall is intercepting the real-time connection the Test panel depends on. This kills the agent's ability to respond after the very first message.
Fourth, computer use and session capture failures, if you're using Copilot Studio agents with computer use actions, UAC prompts, Windows OOBE screens, or an unfocused Remote Desktop session can all break the screenshot mechanism the model needs to function.
All four of these are fixable. I'm going to walk you through every scenario, with exact steps, exact settings paths, and the real-world context Microsoft's own documentation glosses over. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If Microsoft Copilot is not working and you want the single fastest fix that resolves the majority of cases, start here: check whether your connector response is exceeding 500 KB and add a filter. This one issue accounts for more Copilot Studio failures than anything else I encounter in enterprise environments.
Open your agent in Copilot Studio. Go to Tools (for agent-wide actions) or Topics (for topic-specific flows). Find the connector that's failing. Now look at what inputs you're passing to it. Chances are, you're running an open-ended query that returns everything, no result limits, no filters, no field scoping.
For most connectors, you'll see input parameters like Filter, Limit, Top, or $select. Add a limit value, start with 10 to 20 records, and add a filter expression that scopes results to what your agent actually needs. If you're using the ServiceNow connector's Get Knowledge Articles action, specifically, use the Filter input parameter to pass a query expression and the Limit input parameter to cap records returned.
After you configure these inputs, go back to the Test panel and run the same query that was failing before. If the payload was the problem, you'll get a real response within seconds. If you're still hitting an error, move on to the step-by-step section below, there are more layers to check.
One quick note on where to find the inputs UI: for topic-specific connectors, you won't see all available parameters by default. You have to click Advanced inputs on the connector node in the topic canvas to access the full list. That option is easy to miss if you're not looking for it.
This is the foundational fix for HTTP 400 Bad Request errors in Copilot Studio. The error message itself, Error Code: 400, Error Message: Bad Request, gives you almost nothing to work with, which is why so many people spin their wheels on this for hours.
The cause is simple: your connector action returned more than 500 KB of data to Copilot Studio, which is the hard response limit for connector payloads. The fix is to configure the connector inputs so the upstream service sends back only what you need.
Here's how to do it for an agent-wide connector tool:
- In Copilot Studio, select Agents from the left navigation and open the agent that has the broken connector.
- Select Tools to see the full list of actions associated with that agent.
- Select the specific tool you want to configure.
- Select Inputs, then click the edit icon on the input field you want to modify, typically a filter field or a limit field.
For a topic-specific connector tool, the path is slightly different:
- Select Topics and open the topic whose flow contains the broken connector.
- On the topic canvas, click the connector node directly.
- The standard inputs appear automatically, but you need to click Advanced inputs to see the full parameter list, that's where filter and limit options typically live.
- Configure both a filter expression and a row/record limit.
Once you save and return to the Test panel, the HTTP 400 error should stop appearing. You'll know it worked when the agent returns a structured response instead of going silent or throwing the error code.
If you're seeing "This feature has been disabled" in the Copilot Studio prompt builder, your agent's AI prompt capability has been turned off at the environment level. This is an administrative setting, not a bug, and it's one of the most common reasons Copilot Studio stops working for specific teams after an IT policy change.
To fix this, you need Power Platform admin center access. Here's the exact path:
- Open Power Platform admin center and sign in with your administrator credentials.
- In the left nav, go to Manage > Environments.
- Find and select the environment where the error is occurring, make sure you're in the right one, because these settings are per-environment.
- Click Settings in the top toolbar.
- Navigate to Product > Features.
- Find the toggle labeled AI prompts and turn it on.
- Click Save.
After saving, go back to Copilot Studio and try opening the prompt builder again. The "This feature has been disabled" message should be gone. If you're a regular user, not an admin, you'll need to loop in whoever manages your Power Platform environments and share these exact steps with them. Send them this guide if that helps.
Worth knowing: this setting is separate from the overall Copilot Studio access controls. A user can have a valid Copilot Studio license and still be blocked from AI prompts if this toggle is off. It trips up a lot of teams who assume licensing covers everything.
When Microsoft Copilot is not responding after the first message in the Test panel, not throwing an error, just going silent, the culprit is almost always your corporate firewall or proxy server blocking the real-time connection that Copilot Studio depends on for message delivery.
Copilot Studio uses a persistent connection (similar to WebSocket or long-polling) to stream responses back to the Test panel. Corporate firewalls and proxy appliances love killing those connections, especially if they're configured to close idle TCP connections after a timeout or if they inspect and strip certain headers on HTTPS traffic.
Here's what to check and fix:
First, test outside the corporate network. Connect your machine to a mobile hotspot or home network and try the Test panel again. If the agent responds normally, your corporate network is the problem, not Copilot Studio.
Second, work with your network team to allowlist the Copilot Studio endpoints. The specific domains that need to be reachable include *.powerva.microsoft.com and related Azure service endpoints. Your firewall should allow outbound HTTPS (port 443) traffic to these without deep packet inspection or SSL termination.
Third, check proxy bypass rules. If your environment routes browser traffic through an authenticated proxy, the WebSocket-style connections that Copilot Studio uses may not negotiate correctly through the proxy. Add Copilot Studio domains to your proxy bypass list so those requests go direct.
Once network access is corrected, return to the Test panel, refresh the page, and interact with your agent. You should see responses flowing through after each message rather than getting a persistent silent hang.
If your Copilot Studio agent uses computer use actions and you're seeing FailedToTakeScreenshot in the agent transcript, the computer use model has lost the ability to capture the desktop image it needs to operate. When this happens, the computer use action terminates, the agent can't continue the task.
There are three distinct causes, and you need to check all three:
Cause 1: A UAC prompt is blocking the screen. Windows User Account Control prompts are rendered at a higher privilege level than normal desktop applications, which means the screen capture process literally can't see past them. Fix this by ensuring no UAC prompt is displayed when you open the Remote Desktop session. Also verify that UAC isn't set to Always notify, go to Control Panel > User Accounts > Change User Account Control settings and confirm it's not on the highest setting.
Cause 2: Windows OOBE is running on first login. The "Getting things ready" Out Of Box Experience screen appears the first time a new user signs in to a remote computer. The screen capture fails on this image. The fix is straightforward, manually sign in that user account at least one time before any computer use action runs against that machine.
Cause 3: The Remote Desktop session isn't visible. This one catches people off guard. If you're using a browser-based Remote Desktop connection and the browser tab isn't the active focused tab, screen capture fails. Same goes for the Windows App Remote Desktop client, if the window is minimized, capture fails. Before starting any computer use action, make sure the Remote Desktop window is fully visible, in focus, and not behind other windows.
After addressing whichever cause applies, re-run the computer use action. The FailedToTakeScreenshot error should stop appearing in the transcript.
Generative answers in Copilot Studio that point to SharePoint but return nothing are one of the more quietly frustrating issues you can hit. The agent accepts the question. It thinks for a moment. Then it either returns a non-answer or falls through to a fallback topic. The knowledge source looks configured correctly in the UI. What gives?
There are several things to verify when Copilot Studio knowledge sources aren't returning results:
Check SharePoint permissions. The service account or identity that Copilot Studio uses to query your SharePoint knowledge source needs read access to the target site and document libraries. If permissions were recently changed, even at the SharePoint admin level, generative answers can silently fail. Go to the SharePoint site, check site permissions, and confirm the Copilot Studio service identity is included.
Verify the knowledge source is indexed. SharePoint content needs to be crawled and indexed before Copilot Studio can pull from it. New sites or recently uploaded documents may not be immediately available. Wait for indexing to complete, this can take up to 24 hours for large libraries, and test again.
Check Bing-based knowledge sources when publishing fails. If your agent uses Bing as a knowledge source and you're hitting publish failures, Microsoft's documentation specifically calls this out as a known issue. Bing sources require specific licensing and environment configuration. If publishing is blocked because of Bing sources, remove the Bing knowledge source, publish successfully, then re-evaluate whether Bing is actually needed for your use case.
For responsible AI content filter errors on generative answers, you're likely returning content that triggers Microsoft's safety filters. Review what content your knowledge sources contain and whether your query topics overlap with restricted categories. Adjust your agent's topic scope or knowledge source content accordingly.
Advanced Troubleshooting
If the step-by-step fixes above didn't resolve your Microsoft Copilot not working issue, you're dealing with a deeper configuration problem. Here's where to dig next.
Throttling Errors in High-Volume Environments
If your organization is running Copilot Studio agents at scale, multiple agents, high query volume, automated flows triggering agent actions, you may be hitting throttling limits. Microsoft Copilot Studio enforces quotas on message throughput, connector call frequency, and generative AI request rates. When you exceed these, agents start failing intermittently rather than consistently, which makes the problem hard to pin down.
Signs you're being throttled include: agents that work fine in testing but fail under real user load, errors that appear during business hours but not evenings, and inconsistent response times that sometimes result in timeouts. Check the Microsoft Copilot Studio documentation on Quotas and Limits for the current thresholds. If you're approaching those limits, you'll need to distribute load across multiple environments or optimize your agent's connector call frequency.
Security Group Access Issues
There's a known configuration scenario where users outside the Copilot Studio authors security group can unexpectedly access Copilot Studio, and conversely, where intended users find themselves locked out. If you're managing access in an enterprise environment, confirm that your Copilot Studio authors security group is correctly configured in Azure Active Directory and that environment-level access policies in Power Platform admin center match your intended user set.
Checking Event Viewer and Power Automate Flow Runs
When Copilot Studio agents use Power Automate flows as actions, flow failures don't always surface cleanly in the agent transcript. Go to Power Automate, navigate to My flows, and check the run history for flows connected to your agent. Failed runs will show exactly which step failed and what error occurred, this is often far more informative than anything the Copilot Studio UI shows you.
For connector-related failures specifically, look at the inputs and outputs recorded in the failed flow run. If the output shows a large payload size, you've confirmed the 500 KB limit issue. If the input shows incorrect parameter values, your topic configuration is passing bad data to the connector.
Enterprise Network and DNS Resolution
In some domain-joined enterprise environments, DNS resolution for Microsoft cloud service endpoints behaves differently than on consumer networks. If Copilot Studio behaves inconsistently across different machines or locations within your organization, run:
nslookup powerva.microsoft.com
Test-NetConnection -ComputerName powerva.microsoft.com -Port 443from an affected machine and compare the results to an unaffected machine. DNS mismatch or failed port 443 connectivity confirms a network-layer block.
Prevention & Best Practices
Once you've fixed your immediate Microsoft Copilot not working issue, the next job is making sure you don't hit the same wall six weeks from now. A few proactive habits go a long way here.
Build connector response limits into your design from day one. Every connector action you add to a Copilot Studio agent should have explicit input limits configured before you publish. Don't rely on the upstream service to return a sensible amount of data, assume it will return everything it has and design accordingly. Set a Limit or Top value and a filter expression on every connector action, even if you don't think you'll hit the 500 KB ceiling. It's much easier to loosen a limit later than to diagnose a silent failure in production.
Test your agents against realistic data volumes. The Test panel in Copilot Studio is great for functional testing, but it won't catch payload size issues unless you're querying against production-scale data. Before you publish any agent that uses connectors, run test queries against your real data environment with realistic search terms, not sanitized test data that returns three rows.
Set up monitoring on your Power Automate flow runs. If your agents use flows, enable run history notifications on those flows. That way, if a connector action starts failing in production, you'll get an alert rather than hearing about it from an end user two days later.
Document your environment-level policy settings. AI prompts can be disabled, security groups can be modified, and firewall rules can change, often during routine IT maintenance that has nothing to do with Copilot Studio. Keep a record of the Power Platform admin center settings your agents depend on, so when something breaks you know immediately whether a policy change is the culprit.
- Add explicit record limits to every connector action before publishing, default to 20 records and adjust based on real usage patterns
- Manually sign in every remote user account at least once before enabling computer use actions on that machine
- Allowlist Copilot Studio domains in your corporate firewall and proxy bypass rules during initial deployment, don't wait for the Test panel to go silent
- Review your Power Platform environment's AI prompts toggle and security group assignments after any IT policy update or environment refresh
Frequently Asked Questions
Why does my Copilot Studio agent work in testing but fail when real users try it?
This is almost always a data volume problem. In testing, you're probably using carefully scoped queries that return small payloads. Real users ask broader questions that hit connectors harder and return more data, sometimes crossing the 500 KB connector response limit. Go back and add filter expressions and record limits to every connector action in your agent, then re-test with queries that mirror real user behavior. Also check whether you're hitting throttling limits during peak usage hours, which can cause intermittent failures that disappear when traffic drops.
My agent stops responding after the first message in the Test panel. How do I fix it?
This specific pattern, agent responds to message one, then goes completely silent, points to a corporate firewall or proxy blocking the real-time connection Copilot Studio uses for ongoing message delivery. Try connecting to a mobile hotspot and testing again. If it works on a different network, your IT team needs to allowlist Copilot Studio endpoints and ensure the connection isn't being terminated by proxy inspection or idle timeout rules. This isn't a Copilot Studio bug; it's a network configuration issue that has to be solved on the infrastructure side.
I'm getting Error Code 400 Bad Request on my connector action. What does that mean?
Error Code 400 in Copilot Studio on a connector action means your connector returned more than 500 KB of data, Copilot Studio's hard limit for connector responses. The fix is to configure input parameters on the connector action to filter the data the service sends back. Open the connector in Tools or on the topic canvas, click Advanced inputs, and add filter expressions and a record limit. Most connectors (including ServiceNow, SharePoint, and Dynamics connectors) have specific input parameters for this purpose. Once you reduce the response payload below 500 KB, the 400 error stops.
The prompt builder says "This feature has been disabled." I have a Copilot Studio license, why can't I use AI prompts?
Having a Copilot Studio license doesn't automatically enable AI prompts. The AI prompts feature is controlled separately at the Power Platform environment level by an administrator toggle in Power Platform admin center under Product > Features. If an admin turned that toggle off, during a security review, policy update, or environment configuration, you'll see this error regardless of your license status. You need someone with Power Platform admin access to go into the admin center, find your environment's settings, and turn the AI prompts toggle on. Send them the steps in this guide.
My generative answers based on SharePoint aren't returning any results. The knowledge source looks configured correctly.
Configured correctly in the UI doesn't always mean working correctly. Three things to check: first, make sure the service identity Copilot Studio uses has read permissions on the specific SharePoint site and document libraries you're targeting, permission changes at the SharePoint admin level can silently break this. Second, confirm your content is indexed, newly added SharePoint files can take up to 24 hours to become searchable. Third, if your queries overlap with content that triggers Microsoft's responsible AI content filters, generative answers will return nothing rather than flagged content. Narrow your knowledge source scope and test with simpler queries to isolate which of these three is the issue.
I keep getting FailedToTakeScreenshot during computer use actions. I've checked the UAC settings and they look fine.
If UAC is ruled out, check the other two causes. First, is this a user account that's never signed in to the remote machine before? If so, Windows may be displaying the OOBE "Getting things ready" screen on first login, which the screen capture process can't handle. Manually sign in as that user once, let Windows finish its first-login setup, then try the computer use action again. Second, check whether your Remote Desktop session is actually visible and in focus on screen when the action runs. If you're using a browser-based Remote Desktop and that tab isn't the active tab, or if the Windows App Remote Desktop window is minimized, screenshot capture fails every time. Make the Remote Desktop window fully visible before triggering the action.