How does ERP MCP determine F&O environment?
How does the Dynamics 365 ERP MCP Server determine the target Finance & Operations environment when multiple environments (SIT, UAT, and Production) have MCP enabled? In Copilot Studio, the MCP connection only shows the authenticated user and does not expose any environment selection or environment identifier. Is the target F&O environment determined by the underlying Power Platform connection, the MCP client registration, a connection reference, or another routing mechanism? How can administrators verify which F&O environment an MCP-enabled agent is actually connected to?
Fix all annoying Copilot bugs
I’m experiencing an issue with Microsoft Edge on Android. Starting today (September 22, 2026), whenever I try to visit copilot.microsoft.com, Edge automatically redirects me to the Google Play Store to install the Copilot app. I prefer using Copilot in the browser and do not want to install the app. And even when i try to install the copilot app it does not let me do anything and thinks I need a license or subscription to access it like copilot is litterly supposed to be free and also even when i try to get rid of the app redirection it for some dumb reason it redirects me to from copilot.microsoft.com to copilot.com and they put in restrictions like after a lot of chats you must wait for a specific time period and a couple months ago you guys removed the ability to use copilot without registration like come on that is so dumb I want Microsoft Copilot to be fixed revert how copilot was before how is this consumer friendly
Copilot Access not working for only 1 user
Hello, I am facing an issue where I have 1 user that is unable to get answers out of the chatbot on teams. The user is opening the chatbot using the 'open with copilot' option like the rest of the team members, but when they ask a questions, the chatbot returns that it has not found information on the topic, even when the information is in the training documents the chatbot reads off of. Other users can ask the same questions and get valid answers, it is only not working for this specific user. Any suggestions on how to resolve this?
Which Accessible Source Can Reliably Return Current Date, Time, Timezone and UTC Offset?
Question for Microsoft 365 Copilot experts I am trying to implement a reliable "Current Time Validation" control inside a Microsoft 365 Copilot workflow. The requirement is to obtain a machine-readable and repeatable timestamp containing: - Current date - Current time - Time zone identifier - UTC offset For example: 2026-09-16T18:09:00+08:00 Timezone: Asia/Shanghai UTC Offset: +08:00 My goal is not a human-readable world clock page, but a source that Microsoft 365 Copilot can actually access and consume reliably during execution. Business context: The timestamp is used as a mandatory validation gate before generating operational reports. If the timestamp is wrong, downstream conclusions may become invalid because greetings, operating-hours logic, OOO/PTO analysis, and action ownership are all time-dependent. Problems encountered so far I have already tested several approaches and found multiple reliability issues: 1. Conversation context is not a reliable clock source. Copilot may retain or reuse a timestamp from the beginning of a conversation rather than reflecting the actual current time. 2. External "current time" web pages are problematic. Some sites appear to return cached/indexed content when accessed through Copilot, producing timestamps that are clearly inconsistent with real-world elapsed time. 3. Human-readable sources are insufficient. I need a source that returns structured data which can be validated programmatically. 4. Timezone information alone is not enough. The solution must provide: - current date - current time - timezone identifier - UTC offset 5. The source must be repeatable. Two consecutive queries should return updated timestamps reflecting actual elapsed time. Questions 1. Among the data sources that Microsoft 365 Copilot can realistically access today, which source can provide: - date - time - timezone - UTC offset in a machine-readable format? 2. Is there any Microsoft-native source (Microsoft Graph, Outlook, Exchange Online, mailbox settings, tenant settings, calendar services, etc.) that exposes this information directly? 3. Which source would be considered the most reliable and repeatable for workflow-validation purposes? 4. Has anyone implemented a trusted "current time authority" pattern for Microsoft 365 Copilot or Copilot Studio agents? 5. Does Microsoft 365 Copilot have access to a real-time clock source that is guaranteed to be refreshed at query time rather than returning indexed or cached timestamp information? The objective is to establish a trusted and auditable timestamp before generating business reports, task summaries, or workflow decisions. Thanks in advance.
Access to Office App Context and Setting CEA as Default in Microsoft 365 Copilot
Hello everyone, I’m exploring Custom Engine Agents (CEA) in Microsoft 365 Copilot and have two questions regarding their integration with Microsoft 365 applications. Can a Custom Engine Agent access the current Office application context? When a CEA is added to Microsoft 365 Copilot, is there a supported way for the CEA to access the content of the Microsoft 365 application where Copilot is currently being used? For example: Word: Can the CEA read and/or modify the document currently open in Word? Outlook: Can the CEA access the current email/thread and perform write operations such as drafting or modifying content? PowerPoint: Can the CEA access and modify the presentation currently open? Other Microsoft 365 applications: Are similar capabilities available in other applications where Microsoft 365 Copilot is supported? Essentially, I’m trying to understand whether a Custom Engine Agent can leverage the same application context and read/write capabilities that the native Microsoft 365 Copilot has within these applications. If this is supported, what APIs, SDKs, or integration patterns should be used? Can a Custom Engine Agent be configured as the default mode? Is there a supported way to: Disable or bypass the default Microsoft 365 Copilot experience/mode, and Configure a Custom Engine Agent as the default agent/mode that users interact with when they open Copilot? For example, if an organization has a custom agent that should handle the majority of Copilot interactions, can that agent be configured as the default instead of the standard Microsoft 365 Copilot? I’d appreciate any clarification on the current capabilities, limitations, and recommended architecture for these scenarios. ThanksAccess to Office App Context and Setting CEA as Default in Microsoft 365 Copilot
<p>Hello everyone,</p> <p> I’m exploring <strong>Custom Engine Agents (CEA) in Microsoft 365 Copilot</strong> and have two questions regarding their integration with Microsoft 365 applications. </p> <p><strong>1. Can a Custom Engine Agent access the current Office application context?</strong></p> <p> When a CEA is added to Microsoft 365 Copilot, is there a supported way for the CEA to access the content of the Office application where Copilot is currently being used? </p> <p>For example:</p> <ul> <li><strong>Word:</strong> Can the CEA read and/or modify the document currently open in Word?</li> <li><strong>Outlook:</strong> Can the CEA access the current email/thread and perform write operations such as drafting or modifying content?</li> <li><strong>PowerPoint:</strong> Can the CEA access and modify the presentation currently open?</li> <li>Similarly, can it access the context of other Microsoft 365 applications where Copilot is available?</li> </ul> <p> Essentially, I’m trying to understand whether a <strong>Custom Engine Agent can leverage the same application context and read/write capabilities that the native Microsoft 365 Copilot has within these applications</strong>. </p> <p> If this is supported, what APIs, SDKs, or integration patterns should be used? </p> <p><strong>2. Can a Custom Engine Agent be configured as the default mode?</strong></p> <p> Is there a supported way to: </p> <ul> <li>Disable or bypass the default Microsoft 365 Copilot experience/mode, and</li> <li>Configure a <strong>Custom Engine Agent as the default agent/mode</strong> that users interact with when they open Copilot?</li> </ul> <p> For example, if an organization has a custom agent that should handle the majority of Copilot interactions, can that agent be configured as the default instead of the standard Microsoft 365 Copilot? </p> <p> I’d appreciate any clarification on the current capabilities, limitations, or recommended architecture for these scenarios. If there is any official documentation covering these capabilities, please share it as well. </p> <p>Thanks!</p>Access to Office App Context and Setting CEA as Default in Microsoft 365 Copilot
Hello everyone, I’m exploring **Custom Engine Agents (CEA) in Microsoft 365 Copilot** and have two questions regarding their integration with Microsoft 365 applications. ### 1. Can a Custom Engine Agent access the current Office application context? When a CEA is added to Microsoft 365 Copilot, is there a supported way for the CEA to access the content of the Office 365 application where Copilot is currently being used? For example: - **Word:** Can the CEA read and/or modify the document currently open in Word? - **Outlook:** Can the CEA access the current email/thread and perform write operations such as drafting or modifying content? - **PowerPoint:** Can the CEA access and modify the presentation currently open? - Similarly, other Microsoft 365 applications where Copilot is available. Essentially, I’m trying to understand whether a **Custom Engine Agent can leverage the same application context and read/write capabilities that the native Microsoft 365 Copilot has within these applications**. If this is supported, what APIs, SDKs, or integration patterns should be used? ### 2. Can a Custom Engine Agent be configured as the default mode? Is there a supported way to: - Disable or bypass the default Microsoft 365 Copilot experience/mode, and - Configure a **Custom Engine Agent as the default agent/mode** that users interact with when they open Copilot? For example, if an organization has a custom agent that should handle the majority of Copilot interactions, can that agent be configured as the default instead of the standard Microsoft 365 Copilot? I’d appreciate any clarification on the current capabilities, limitations, or recommended architecture for these scenarios. Thanks
Microsoft Copilot 365 Personal Premium limits
In my Copilot Notebook, I deliberately loaded 20 PDF files in order to test Copilot’s grounding behavior across the full set of available references. At the time this testing setup was created, 20 references represented the effective grounding limit described for Copilot Notebooks, meaning that these references were expected to form the source base used by Copilot when generating grounded responses. The references consisted of fully functional, original academic textbooks containing relevant and up-to-date scientific information, mostly published within the last ten years. Importantly, the sources do not differ from one another in terms of accessibility, file type, availability, or how they were added to the notebook. They are all PDF files, they are all available in the same environment, and there is no obvious difference in access conditions that would explain why some are consistently used while others are repeatedly treated as inaccessible, unavailable, summarized, or skipped. The purpose of the test was therefore not simply to see whether Copilot could access 20 files, but whether it could actually ground its answers in the complete reference set when explicitly instructed to analyze all available sources. Despite this, in approximately 99.9% of my tests, Copilot appears to ground its responses in only 3 to 5 of the 20 available references, often repeatedly using the same documents. When I ask what happened to the remaining sources, Copilot gives different explanations. Sometimes it says that it does not have access to certain files. Sometimes it says that it only received a summary of the file. Sometimes it says that a step involved in retrieving or processing the information failed. The way Copilot explains this often makes it sound as if access to the uploaded files depends on some external or intermediate system, rather than being something Copilot itself can directly control. This is difficult to understand from a user perspective because the files are already uploaded into the Copilot environment and were specifically provided as source material for analysis. The practical result is that a task explicitly requesting analysis of 20 sources often produces an answer based on only 3 to 5 of them. For academic or research use, this is a serious limitation. If 15 to 17 out of 20 carefully selected sources are not actually examined, then the final synthesis cannot realistically represent the full source base. This also creates uncertainty about what Copilot means when it claims to have used the provided materials. My question to Microsoft is: Is there a technical limit on how much information Copilot can actually retrieve, open, and analyze from uploaded files during a single task or session? If such a limit exists, what is that limit? And why, when 20 valid PDF sources are uploaded and Copilot is explicitly instructed to analyze all of them, does it so often appear to open only 3 to 5 files, while describing the others as inaccessible, summarized, or unavailable because some retrieval step failed?Microsoft Copilot 365
To Microsoft: Serious Concerns Regarding the Actual Capabilities of Microsoft Copilot Microsoft, After 12 consecutive days of intensive testing of Microsoft Copilot, for approximately eight hours per day — around 96 hours of practical use in total — I have serious concerns about the accuracy of the way Copilot's functions and capabilities are described and presented by Microsoft. What I have observed in actual use is repeatedly and substantially different from what the product is presented as being capable of doing. This conclusion is not based on a single unsuccessful prompt, an isolated error, or a short test. It is based on repeated testing over many days, involving continuous academic, analytical, document-based, and multi-step tasks. One of the most serious problems is Copilot's inability to reliably maintain and use conversational context even within the same active session. For example, Copilot can generate a substantial piece of text and, in the immediately following interaction, claim that it cannot see or access that same text. It may ask the user to provide again information or content that Copilot itself generated only one response earlier. This makes it impossible to rely on the system for genuine sequential work. During testing, the same general problem has appeared in different forms: Copilot fails to return reliably to earlier tasks, loses access to information already established within the conversation, fails to connect consecutive instructions, and sometimes behaves as though previous parts of the same active session do not exist. This is particularly serious when Copilot is used for academic or research work. A workflow may require the system first to generate or analyse material, then classify it, compare it with another part of the work, identify its sources, reorganise it, and finally continue developing it. If Copilot cannot reliably access the result of the immediately preceding step, such a workflow becomes fundamentally unreliable. After approximately 96 hours of direct testing, it is increasingly difficult to regard these problems simply as occasional technical limitations. The discrepancy between Microsoft's descriptions of Copilot and the behaviour actually observed during sustained use is substantial enough to raise a much more serious question: whether the functions and capabilities attributed to Copilot in Microsoft's product descriptions accurately represent what the system can actually and reliably do in normal use. From the user's perspective, the current experience creates the impression that Microsoft's claims about Copilot's capabilities are misleading. A capability should not be considered a genuine product capability merely because the system can occasionally perform it under favourable conditions. If a feature is presented to users as part of the product's functionality, users should reasonably be able to expect that functionality to operate consistently enough to be relied upon. After 12 days of testing, that has not been my experience. The difference between the advertised or described capabilities and the actual behaviour of Copilot is not minor. In several fundamental areas — particularly conversational continuity, access to previous work within the same session, multi-step task execution, and reliable reuse of previously generated content — the practical experience does not correspond to the expectations created by Microsoft's descriptions of the product. After nearly 100 hours of testing, I am therefore questioning not simply the quality of Copilot, but the accuracy and transparency of Microsoft's representation of what Copilot is actually capable of doing. If Microsoft describes Copilot as possessing capabilities that repeatedly cannot be reproduced in sustained real-world use, then the issue is no longer merely whether Copilot occasionally makes mistakes. The issue is whether users are being given an accurate representation of the product they are being asked to use and pay for.
