Hey Copilot Voice Function is not working
I am trying to use the "Hey, Copilot" feature in the Copilot app on my PC. It is not working because the voice assistant does not open when I say the wake phrase. I have already contacted technical support, and after going through all the troubleshooting steps, we were unable to find a solution. My microphone is working perfectly because if I launch the voice assistant manually, I can have a voice conversation without any issues. Microsoft Copilot version: 150.0.4078.96 (64-bit) Windows 11 installed "Hey, Copilot" is enabled Mic permissions are enabled Manual voice conversations work correctly Reinstalled Copilot and restarted the PC Issue: Saying "Hey, Copilot" does not activate voice mode.
Problem that copilot is unable to see all my emails in outlook
Copilot returns incomplete http://outlook.com/ email search results while Outlook Desktop and Outlook Web return complete results Product Microsoft Copilot (Windows App) Microsoft Copilot (Web) http://outlook.com/ Outlook Desktop Outlook on the Web Issue Summary Copilot is returning incomplete email search results from my http://outlook.com/ mailbox. The same mailbox searched directly in Outlook Desktop and Outlook on the Web returns complete and accurate results, but Copilot only returns a subset of the matching emails. The issue occurs in both the Copilot Windows application and Copilot on the web, suggesting the problem is not device-specific. Environment Microsoft Account Personal Microsoft account http://outlook.com/ mailbox Microsoft 365 Personal trial currently active Devices Windows laptop Completely rebuilt from scratch to troubleshoot this issue Internal storage wiped Fresh Windows installation performed All current Windows updates installed All current Microsoft 365 / Office updates installed Applications Tested Outlook Desktop (latest version) Outlook on the Web Microsoft Copilot for Windows Microsoft Copilot on the Web Account Status Same Microsoft account used for Outlook and Copilot Mailbox accessible and functioning normally Mail synchronization appears healthy Outlook search functioning correctly Problem Description On Monday 3 August 2026, my Inbox contained 12 messages. Examples included: Tesco http://amazon.co.uk/ eBay Yahoo Microsoft Account Team Microsoft 365 When I asked Copilot to list emails received on 3 August 2026, Copilot returned only a subset of those emails. Copilot was able to locate: Tesco order confirmation Tesco order amendment Microsoft 365 trial activation Microsoft account password change However, Copilot did not return several emails that were visibly present in the Inbox, including Amazon, eBay, Yahoo and other Microsoft account notifications. Expected Result Copilot should return all emails matching the requested date range, consistent with Outlook Desktop Search and Outlook Web Search. Actual Result Copilot returns only a partial subset of the matching emails despite the emails being clearly present in the mailbox. Diagnostic Testing Performed Outlook Desktop Search Result: ✅ Returns all expected emails. Outlook Web Search Result: ✅ Returns all expected emails. Copilot for Windows Result: ❌ Returns only a subset of emails. Copilot Web Result: ❌ Returns the same subset of emails. Operating System Result: ✅ Fresh Windows installation completed. Office Installation Result: ✅ Fully updated. Mailbox Access Result: ✅ Mailbox functioning normally. Why I Believe This Is a Copilot Search Service Issue The issue reproduces: Across multiple Copilot clients On a freshly rebuilt device While Outlook Desktop Search works correctly While Outlook Web Search works correctly Since both Outlook clients return complete results and both Copilot clients return incomplete results, the evidence suggests a discrepancy in the mailbox search/indexing layer used by Copilot rather than a problem with Windows, Office, Outlook indexing, or the local device. Request Please investigate: Whether Copilot is using a different mailbox index from Outlook Search. Whether my mailbox has been only partially ingested into the Copilot search service. Whether there are known issues affecting http://outlook.com/ personal accounts and Copilot email retrieval. Whether Microsoft can trigger a reindex, resynchronization, or repair of the mailbox content used by Copilot. Whether there are any diagnostic tools available to compare Outlook Search results versus Copilot Search results. Evidence Available I can provide: Screenshots showing 12 emails present in Outlook Inbox on 3 August 2026. Screenshots of Outlook Desktop search results. Screenshots of Outlook Web search results. Screenshots showing Copilot returning only a subset of those emails.Lessons Learned #551: Azure SQL Connection Timeouts: Three Things to Check
An application starts reporting intermittent timeouts when connecting to Azure SQL Database. Some requests succeed, others fail, and a test from a developer’s laptop works perfectly. The database appears online, no recent deployment seems related, and the natural reaction is to ask: Is Azure SQL unavailable? Is the firewall blocking the connection? Should we increase the connection timeout? Should we change the driver or scale the database? Those are reasonable questions, but they may lead the investigation in the wrong direction. The most important lesson is simple: A timeout tells us how long the application waited. It does not tell us what the application was waiting for. Not every “SQL timeout” happens inside Azure SQL From the application’s point of view, opening a database connection may involve several operations: Resolving the server name. Reaching the SQL endpoint. Obtaining a Microsoft Entra access token. Waiting for an available pooled connection. Completing the SQL login. Executing the first command. When all these operations are reported through the same application method or log entry, it can look as though Azure SQL took thirty seconds to accept the connection. In reality, only part of that time may have been spent connecting to the database. In one anonymized support scenario, the application experienced problems mainly on its first connection. Network tests were successful and no corresponding SQL connection failure was identified. The investigation eventually showed that access-token acquisition was consuming a significant part of the available time. Increasing the SQL timeout or changing the firewall would not have addressed the real delay. Check 1: Capture the complete error and the exact time A screenshot containing only “Connection Timeout Expired” is rarely enough. Capture: The complete exception and inner exception. The operation being performed. The driver and version. The authentication method. The exact timestamp in UTC. Whether the issue affects every connection or only some of them. The wording around the timeout matters. For example, a timeout while obtaining a connection from the pool points toward the application’s pooling and concurrency behavior. A pre-login or TLS error belongs to a different investigation. A command timeout after the connection was established is usually a query-performance problem rather than a connection problem. Check 2: Measure the application timeline The application should record important operations separately. A simple timeline can completely change the investigation: 10:14:20.100 Token acquisition started 10:14:28.400 Token acquired 10:14:28.405 SQL connection started 10:14:29.050 SQL connection established The complete operation took almost nine seconds, but Azure SQL connection establishment took less than one second. Useful measurements include: Token-acquisition duration. Time waiting for a pooled connection. SQL connection-open duration. SQL command duration. Number of retry attempts. Applications using Microsoft Entra authentication must obtain an access token before authenticating to Azure SQL. Measuring that operation separately helps distinguish an identity delay from a database connectivity problem. This is particularly useful when the issue appears: On the first connection after startup. After a token expires. Only with Managed Identity or Workload Identity. Intermittently, while SQL authentication connections remain unaffected. Check 3: Test from the application environment A successful connection from a laptop does not validate the path used by an application running in: Azure App Service. Azure Functions. Azure Kubernetes Service. A virtual machine. An on-premises application server. A container or integration runtime. The laptop and the application may use different DNS servers, routes, firewalls, proxies and identities. Connectivity and DNS tests should therefore be performed from the environment that is actually failing. This becomes especially important when Private Endpoint is used. The application should continue connecting with: <server>.database.windows.net It should not use the Private Endpoint IP address or the privatelink.database.windows.net hostname directly. Direct login attempts using the private IP or the private-link FQDN fail; the normal logical-server FQDN must remain in the connection string. From the affected environment, confirm that: The expected DNS server answers the request. The server FQDN resolves to the expected private IP. The Private Endpoint connection is approved. The Private DNS zone is linked correctly. The resolved address is reachable through the intended route. A test from an unrelated machine is still useful for comparison, but it does not prove that the application path is healthy. Observed symptom Likely investigation area Timeout while obtaining a connection from the pool Application connection pooling Server name cannot be resolved DNS TCP connection to the endpoint cannot be established Network path, firewall or routing Error during the pre-login handshake TLS, driver, network interruption or pre-login processing Authentication or access-token error Microsoft Entra authentication, identity or token acquisition Timeout during the post-login phase Login completion, session initialization or server-side processing Execution or command timeout after connecting Query execution and database performance Avoid changing several things at once During a production incident, it is tempting to: Increase the timeout. Add firewall rules. Change the connection policy. Upgrade the driver. Restart the application. Clear connection pools. Applying several changes together makes it difficult to determine which one helped, and some may only hide the symptom. A better approach is to define one hypothesis: We believe DNS in the application environment is resolving the public endpoint instead of the Private Endpoint. Then define: The evidence supporting the hypothesis. One controlled change. The expected result. How the result will be measured. How the change will be reverted. Azure SQL supports Proxy and Redirect connection policies, which determine how traffic flows after reaching the Azure SQL gateway. The policy is configured for the logical server, so it should be verified before making firewall assumptions or changes. What should we collect before opening a support request? A small but precise evidence package can avoid several rounds of questions: Complete error and inner exception. Exact UTC timestamps. Application platform and location. Public or Private Endpoint. Server FQDN used by the application. Driver and version. Authentication method. Token, pool, connection and command durations. DNS result from the affected environment. Whether the issue is constant, intermittent or limited to the first connection. Recent application, network, identity or configuration changes.
Copilot in Word can't read chat attachments; Word for web file picker shows “no token obtained”
Summary of the issue I am seeing a persistent failure with Copilot attachments specifically inside Microsoft Word. Copilot in Word desktop and Word for the web can recognize an uploaded chat attachment by filename or OneDrive URL, but it cannot read the file contents. It reports the uploaded file as empty, corrupted, or in a format it cannot process. The same files are successfully read by standalone Microsoft 365 Copilot Chat using the same Microsoft account, and file uploads also work in Excel Copilot and PowerPoint Copilot. Failure started 10 days ago, with no obvious changes in settings on my end. The most useful diagnostic clue so far is that Word for the web’s Copilot attachment/file-picker path has also failed before any file was selected, showing “Something went wrong, please try again or refresh the page, no token obtained.” In Chrome, Word for the web produced a SharePoint-style error page with a correlation ID. This makes the issue look less like a bad file or local Word installation problem and more like a Word Copilot attachment-picker, OneDrive/SharePoint authorization-token, or file-handoff problem. Environment and scope Windows 11, Pro. Microsoft Word desktop: issue reproduced after updating Office and Windows. Word for the web: issue reproduced in Edge, Edge InPrivate, and Chrome. Standalone Microsoft 365 Copilot Chat / copilot.microsoft.com / m365.cloud.microsoft/chat: uploaded files can be read successfully with the same Microsoft account. Excel Copilot and PowerPoint Copilot: uploaded files work. OneDrive in Chrome: upload/download and file access work normally with the same account. Same Microsoft account used throughout. File types tested include tiny TXT files, PDFs, and DOCX files, including a complex DOCX. Copilot in Word can read the active Word document normally; the failure is limited to files uploaded as Copilot chat attachments inside Word. Observed behavior In Word desktop, Copilot chat accepts or recognizes the attachment metadata, including filename and sometimes a OneDrive URL, but when asked to read or summarize the file it says the file appears to be empty, corrupted, or in a format it cannot process. This happens even with a very small TXT test file. In Word for the web, the same general failure occurs. In one clean test, I created a brand-new blank Word document in Word for the web, opened Copilot, attached a tiny TXT file, and asked what the uploaded TXT file said. Copilot responded: “The uploaded file ingestion_test_731_1915.txt appears to be empty, corrupted, or in a format I can’t process, so I can’t read any text from it.” In another Word for the web test, clicking Copilot’s “+” attachment button and choosing either “My Files” or “Recent” opened a mostly blank window saying: “Something went wrong, please try again or refresh the page, no token obtained.” This occurred before any file was selected. In Chrome, Word for the web produced this error when trying to use the Copilot attachment flow: “Sorry, something went wrong. An unexpected error has occurred. Technical Details: Troubleshoot issues with Microsoft SharePoint Foundation.” The error included Correlation ID 64062ea2-3083-8000-a0f7-fbf4f6bb617d and Date/Time 8/4/2026 12:21:38 PM. Evidence matrix Test Result Standalone Microsoft 365 Copilot Chat / copilot.microsoft.com DOCX, PDF, and TXT uploads can be read successfully with the same account. OneDrive in Chrome Upload, download, and file access work normally. Excel Copilot Uploaded files work. PowerPoint Copilot Uploaded files work. Word desktop Copilot Attachments are recognized but reported as empty, corrupted, or unprocessable. Word for the web in Edge/InPrivate Tiny TXT attachment reported as empty, corrupted, or unprocessable. Word for the web attachment picker “No token obtained” message before file selection. Word for the web in Chrome SharePoint Foundation-style error with correlation ID 64062ea2-3083-8000-a0f7-fbf4f6bb617d. Word Copilot reading the active document Works normally. Troubleshooting already tried Updated Microsoft Office / Microsoft 365 desktop apps. Updated Windows. Restarted Word multiple times. Restarted the computer multiple times. Signed out and signed back in. Confirmed that the same Microsoft account is being used; there is only one Microsoft account involved. Toggled connected experiences off and back on, including restarts between changes. Started Word in Safe Mode. In Safe Mode, Copilot chat opened but did not activate properly; the Copilot pane appeared to cycle in the background and sub-windows were blank/unusable. Tested with a brand-new blank Word document in Word for the web. Tested in Edge, Edge InPrivate, and Chrome. Tested with very small TXT files as well as PDF and DOCX files. Confirmed OneDrive itself works normally in Chrome by uploading and accessing files successfully. Confirmed standalone Copilot and Excel/PowerPoint Copilot can process uploaded files successfully. Why this does not look like a local file or browser problem The same uploaded files work in standalone Microsoft 365 Copilot Chat, and OneDrive upload/download works normally. The issue also reproduces across Word desktop and Word for the web, across multiple browsers, and with a brand-new blank Word document. Because Word Copilot can read the active document but cannot acquire or process uploaded chat attachments, the failure appears isolated to the Word-integrated Copilot attachment picker, authorization-token acquisition, or OneDrive/SharePoint file-handoff path. Most likely failure area My current working theory is that Word-integrated Copilot is failing to obtain or pass the required SharePoint/OneDrive authorization token for Copilot chat attachments. The “no token obtained” message and the SharePoint Foundation correlation ID point toward the file-picker or backend handoff path rather than file contents. It may be account-specific, feature-flight/routing-specific, or a Microsoft-side regression affecting Word Copilot attachment handling. Request for help Has anyone seen Word Copilot attachments fail in this way while standalone Copilot, OneDrive, Excel Copilot, and PowerPoint Copilot all still work? Are there known Word Copilot attachment-picker, OneDrive/SharePoint token, or feature-routing issues that can affect only Word-integrated Copilot? If Microsoft support or engineering can trace backend logs, the most relevant correlation ID I have is 64062ea2-3083-8000-a0f7-fbf4f6bb617d from 8/4/2026 at 12:21:38 PM in Word for the web in Chrome. I would especially appreciate suggestions for anything beyond the standard local troubleshooting already tried. At this point, the pattern suggests the next useful step is probably backend investigation of the Word Copilot attachment/file-picker authorization flow rather than more file-format testing or local repair.Registry Inventory in Microsoft Intune: Verifying What’s on Your Devices
By: Madison Cooks, Product Manager | Microsoft Intune IT admins need a reliable way to confirm how Windows devices are configured, especially when troubleshooting, validating compliance, or investigating security posture. Policy assignment alone doesn’t always show what’s present on the device and getting registry visibility at scale has often required custom discovery or remediation scripts that take time to build, test, and maintain. With Microsoft Intune’s July (2607) release, device inventory will include Windows registry data, helping IT admins verify a device’s actual configuration, not just the policy assigned. With a new Device inventory property for registry keys, you define the keys you care about in the properties catalog, and Intune collects them for you. There’s no collection logic to build or keep running. This makes registry-based configuration checks easier to operationalize across managed Windows devices, so teams can spend less time maintaining scripts and more time acting on the data. Figure 1: Microsoft Intune device inventory profile creation screen showing the Properties picker with the Registry category selected for inventory data collection. What registry data you collect Registry data collection is configured through the existing properties catalog. For each entry, provide a registry key path and, when needed, a value name. For every targeted device, the device agent attempts collection and reports: Registry key path Value name Value type Value data Microsoft Intune device inventory profile configuration page showing registry key collection settings, including registry path, collection pattern options, and value name fields. The initial release supports the following collection patterns designed for common admin scenarios that use HKEY_LOCAL_MACHINE (HKLM) paths. Single value Specify a registry path and value name to collect one value from that path. For example, collect Secure Boot certificate servicing status from HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot by using values such as UEFICA2023Status, UEFICA2023Error, or UEFICA2023ErrorEvent. All values under a path, non-recursive Specify a registry path to collect all values directly under that path. This pattern doesn't include subkeys. For example, collect values directly under a Windows Update configuration path to help validate expected settings. Same value across subkeys Specify a base registry key path and a value name to collect that value from each immediate subkey. For example, collect DHCP status across network interface subkeys under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces. Where registry inventory data appears After collection, registry inventory data will be available in Device inventory at initial release. We’ll expand access to registry data in the coming months, including support in additional reporting and exploration experiences. Microsoft Intune Device Inventory page displaying collected Windows registry data for a device, including registry key paths, values, collection status, and timestamps. This makes registry data available alongside other inventory signals, so admins can use familiar tools to investigate configuration, validate device state, and support troubleshooting without building separate collection scripts. How admins use this You can collect registry data and view it per device in Device inventory - a verified record of each endpoint’s actual configuration and a key source of settings data on each endpoint. This helps answer questions like: Is a setting actually enabled on the device? Which app, version, or configuration is installed? Did a policy apply correctly? Why is this device behaving differently from the rest? Registry data collection in Device inventory is included with Microsoft Intune Plan 1. Collection results and limits If a registry value exists but doesn’t contain data, collection succeeds and the value appears as empty. If the registry path or value name doesn’t exist on a device, that device reports Not found for the collection result. Collection continues for all other devices, so one missing value won’t block results from devices where the value exists. Registry inventory includes safeguards to keep collection focused and manageable. Each collected registry value is capped at 6 KB, and each device can collect up to 100 registry keys. If a value or device exceeds these limits, collection skips the excess data and reports the applicable result for that device. These limits help manage data volume, maintain service performance, and reduce the risk of over-collection. Registry inventory is designed for configuration visibility and troubleshooting, not for collecting sensitive or confidential data. Built-in heuristic detection helps identify and prevent ingestion of values that may contain secrets, credentials, authentication tokens, certificates, private keys, connection strings, or other data that could grant access if exposed. If a value is flagged as potentially sensitive, it isn’t collected. Collection is limited to HKEY_LOCAL_MACHINE (HKLM) paths. This keeps inventory focused on device-level configuration and avoids user-specific registry contexts. Summary Registry inventory in Microsoft Intune helps admins collect Windows registry data in a native, declarative way. Instead of maintaining custom scripts for common inventory scenarios, admins can configure registry collection in the properties catalog and query the results through familiar Intune reporting experiences. Use registry inventory for configuration visibility and troubleshooting across managed Windows devices. As you plan your collection strategy, focus on device-level HKLM data, avoid sensitive values, and remember collection limits to keep inventory targeted and manageable. If you have any feedback or questions, leave a comment below or reach out to us on X @IntuneSuppTeam.URLs not accessible when running python script in sandbox
I have a script: import requests try: r = requests.get("https://google.com", timeout=10) print("Status:", r.status_code) print("Headers:", dict(r.headers)) print("Body:", r.text[:300]) except Exception as e: print(repr(e)) When I run it with an agent, it gives me this error: I have no idea how to make the URL valid for the conversation and it doesn't work with any URL I have provided so far.
Copilot pain points....
Guys… seriously… we need some improvements here. I’m not asking Copilot to solve quantum physics or decode alien transmissions. I’m asking a Microsoft program for help with a Microsoft program. You’d think that would be the one scenario where Copilot would shine, right? Like, “Ah yes, my home turf, allow me to demonstrate competence.” But no. I can’t even get Copilot to correctly explain how to do basic SharePoint tasks. BASIC. As in, “click the thing, then click the other thing.” Instead I get a TED Talk about SharePoint philosophy and a guided meditation on patience. And then there’s the folder comparison fiasco. I want Copilot to do something so simple it should practically be a reflex: Compare two folders on my hard drive and tell me if they’re identical. Copilot’s response? “Absolutely, I can do that!” Followed immediately by an ever‑expanding scavenger hunt of things I apparently need to do first. It’s like asking someone to hand you a screwdriver and they say, “Sure, but first you’ll need to assemble this IKEA shelving unit, install three dependencies, sacrifice a goat, and agree to a quest.” I’m glad to hear you’re merging all the copilots into one “super Copilot.” Great idea. Fantastic. But let’s be honest — I’m praying the one that survives is the personal Copilot, because Copilot 365… whew. That thing feels like it was built by a committee that communicates exclusively through interpretive dance. And don’t even get me started on the wrapper versions. Those are like Copilot wearing a Halloween costume of itself, but the costume is made of cardboard and disappointment. And by the way — I’m STILL waiting for Copilot to create an app or program that automatically files my Outlook emails into folders. This is not a moon landing. This is not a Mars rover. This is not a Nobel Prize category. This is a simple, everyday, normal-person task. Yet somehow Copilot treats it like I’ve asked it to build the next Windows release from scratch using only a spoon and positive thinking. Come on, guys. We love the vision. We love the potential. But the basics need to work before the magic tricks do.Feedback: Loop, To Do, and Copilot/Work IQ Have Fundamental Data-Discoverability Gaps
**Category:** Microsoft Loop / Microsoft To Do / Microsoft 365 Copilot (Work IQ) **Summary:** A day-long, hands-on investigation (creating, sharing, and re-locating the same task list through multiple M365 surfaces) surfaced several structural issues that prevent Copilot from reliably grounding on a user's own daily task content — even when using Microsoft's own recommended tools. Posting this as consolidated feedback rather than separate one-off tickets because the issues share a common root cause: **fragmented storage architecture that isn't transparent to end users, and inconsistent Copilot/Work IQ coverage across first-party productivity apps.** --- ## 1. Loop "My workspace" content is invisible to Copilot/Search — and there's no UI signal telling users this When a Loop page/component is created directly in the Loop app (loop.cloud.microsoft), specifically in **My workspace**, it is stored in a user-owned **SharePoint Embedded container** (internally referenced as `CSP_...` in URLs). This container: - Has no site interface and is **not surfaced in standard SharePoint/Graph search** by default (confirmed via Microsoft's own SharePoint Embedded dev docs: *"SPE content is in the SharePoint index but not surfaced in standard SharePoint searching"*). - Is **not listed** in Work IQ's documented "Supported functionality" (Email, Meetings, OneDrive/SharePoint documents, Teams messages, Planner plans, Enterprise search — no mention of this container type). - Cannot be opened/read via Microsoft Graph search or Copilot grounding, regardless of how many times the content is re-shared via email or Teams link. **Reproduction:** Create a Loop page in My workspace → copy the page's share link → paste into an email or Teams message → send to yourself. The email/message is indexed and searchable, but the **linked Loop content is not** — Copilot can see that a link was shared, but cannot read what's on the other end. **Why this matters:** Users have no way to know, from the UI, whether the Loop content they just created lives in an indexable location or a hidden one. The same "Loop Components" button behaves completely differently depending on entry point (see #2). --- ## 2. The exact same UI action ("Loop Components" button / sharing a component) produces content in *different, non-obvious storage backends* depending on where it's triggered Through direct testing, the following was observed: | Creation path | Resulting storage | Discoverable by Copilot/Search? | | Loop app → My workspace → new page | SharePoint Embedded (`CSP_...` container) | ❌ No | | Loop app → page → convert element to "Component" → copy link → paste in email | Still the same `CSP_...` container | ❌ No | | **Teams chat** → Loop Components button → new component → send | OneDrive ("Microsoft Teams Chat Files" folder) | ✅ Yes | | Loop component shared as `-my.sharepoint.com/personal/...` link | Personal OneDrive | ✅ Yes | There is **no visual indicator** in the Loop or Teams UI that distinguishes these two families of storage. A user cannot tell, by looking at a component, whether it will ever be indexed. This makes "where should I put my recurring task tracker" an genuinely difficult, undocumented question for end users — we had to reverse-engineer the answer by inspecting URL domains across multiple test messages. **Ask:** Either (a) unify storage so all Loop content is indexable by default, or (b) add a visible badge/tooltip in the Loop UI indicating "this content is stored in your personal workspace and won't be searchable/Copilot-discoverable outside this page" vs. "this content is in a shared, indexable location." --- ## 3. Loop "add to workspace" appears to create a shortcut, not a true move — ownership stays with the original creator/location Adding an existing Loop component to a different (e.g., team) workspace generated a `.url` shortcut file rather than relocating the actual `.loop` file. The original file's location (and therefore its retention/discoverability characteristics) did not change. This isn't clearly communicated in the product — "add to workspace" reads like the content now *belongs* to that workspace. --- ## 4. Retention/discoverability interplay between Teams chat cleanup policies and Loop files needs clearer documentation Per Microsoft's own retention docs, Teams message retention policies explicitly **exclude** files ("Emails and files that you use with Teams aren't included in retention policies for Teams"), and Loop files created in Teams chat land in the auto-generated "Microsoft Teams Chat Files" OneDrive folder, which does **not** appear on the list of folders with built-in expiration (unlike "Microsoft Copilot Chat Files," which auto-deletes after 30 days). This is good news for users worried about losing content when chats are periodically cleared — but it is **not documented anywhere user-facing**, and users are left to guess (or ask a forum) whether their task tracker will survive a chat retention sweep. **Ask:** Add a plain-language note to Loop/Teams documentation clarifying that Loop files persist independently of chat message retention, unless a tenant admin has separately applied a retention label to that specific OneDrive folder. --- ## 5. Microsoft To Do is officially recommended for "individual tasks" but is **not included in Work IQ's supported data sources** Microsoft's own guidance says: *"To work on individual tasks... start with To Do."* However, Work IQ's documented supported functionality list (Email, Meetings/calendar, OneDrive/SharePoint docs, Teams messages, People, **Microsoft Planner plans**, Enterprise search) explicitly names Planner but **omits To Do entirely**. This means: - Copilot Chat cannot answer "what's on my To Do list today" — it has no grounding access to To Do task data at all. - The only path to integrate To Do with an agent is a custom-built Graph API plugin (`/me/todo/lists`), which requires developer effort most end users can't do themselves. - Multiple community threads (Tech Community, 2025–2026) confirm this gap has been raised repeatedly with no resolution: *"Doesn't look like Co-Pilot can natively interact with To Do just yet."* **Ask:** Add Microsoft To Do to Work IQ's supported data sources. This is the most basic, universally-needed personal productivity data source in the entire suite, and it's currently a blind spot for the product Microsoft itself recommends as the default answer for personal task tracking. --- ## 6. To Do's flagged-email task preview truncates mid-sentence with no way to see the rest without leaving the app When an email is flagged and appears in To Do's "Flagged email" list, the task detail pane shows a **truncated preview** of the email body — often cutting off mid-sentence at exactly the point where the actionable instruction is (e.g., "...we'll be looking for the item from" — no continuation). The only way to read the rest is to click "Open in Outlook" and leave the app entirely, defeating the purpose of a quick task-review pane. There is unused whitespace below the preview in the current UI, suggesting this is a low-effort truncation limit rather than a real space constraint. This has been raised in the Microsoft Community forum since **January 2024** with zero replies/action: *"Having to open each email in a separate window is highly inefficient... Ideally, the email preview should take up whatever space remains in that righthand column."* **Ask:** Either expand the preview pane to show full email body (space is clearly available), or make it resizable/scrollable so users aren't forced to leave the app to read one more sentence. --- ## 7. Overall: four overlapping personal/team task tools (To Do, Planner, Loop task lists, Teams Tasks app) with unclear, undocumented boundaries and uneven Copilot support Each tool markets itself as suitable for slightly different scenarios, but: - Sync between Loop task components and Planner reportedly creates a **new Plan per Loop component** rather than linking to an existing one — a bug/limitation raised on Tech Community since at least Oct 2025, still unresolved as of mid-2026, and explicitly called out by a commenter as something that "should have been a release blocker." - "Add to Microsoft To Do" from Teams Copilot meeting recap action items has been intermittently available/unavailable, per community reports, with no clear roadmap status. - None of this is explained in a single, current, authoritative "which tool for which scenario, and what's the Copilot support level for each" reference. **Ask:** Publish (and keep updated) a single official comparison page that includes not just feature differences between To Do/Planner/Loop/Teams Tasks, but explicitly states **Copilot/Work IQ grounding support level** for each, so users can make an informed choice up front instead of discovering gaps through trial and error. --- ## Why this matters Individually, each of these is a minor rough edge. Together, they mean that a fairly universal, basic task — "let Copilot help me track and recall my daily to-do list" — currently has **no reliable, fully-supported path** using only first-party Microsoft tools, despite Microsoft actively promoting an "AI-native," Copilot-everywhere vision across the 450M-seat M365 install base. A technically proficient user (myself) needed roughly a full day of trial-and-error, URL-inspection, and cross-referencing public docs to arrive at a partial workaround. That is not a reasonable bar for the average user, and it undercuts trust in Copilot's promise of "ask me anything about your work." Happy to provide full repro steps, screenshots, or file/URL samples (redacted) if useful for triage.
