From PC to Home Window: AI as Data Surgeon
Hello Copilot Community, I’d like to share a vision for the future of AI in Windows and beyond: evolving from a reactive assistant into a Data Surgeon — diagnosing, repairing, and reconstructing the lifeblood of modern life: data. 🩺 Diagnose Scan for corruption in files, registries, and hardware sectors Detect anomalies with machine learning and predict failures before they happen 🛠 Repair Auto-heal OS inconsistencies, registry errors, and driver mismatches Reconstruct corrupted files using backups, metadata, and contextual inference 🧬 Reconstruct Repopulate missing data from previous versions and cloud syncs Fill gaps in documents, databases, or media with AI-driven interpolation 🧑⚕️ Prescribe & Prevent Recommend preventive actions: backup schedules, hardware upgrades, cooling solutions Provide digital wellness reports — like a health checkup for your PC 🛤 Roadmap Toward the “Home Window” 2025–2027: AI-assisted diagnostics and repair tools 2027–2030: Household integration and predictive maintenance — the “Home Window Baby” stage 2030–2035: Cross-domain AI collaboration (social media, banking, utilities) 2035–2040: Fully fledged “Home Window” — essential for every modern home Discussion Prompt: How do you see Copilot evolving into this role? What technical milestones or safeguards would be essential? Could this align with Microsoft’s roadmap for Copilot in Windows and household AI?Copilot Connector for DevOps - Crawl Account = Search Admin?
Hi all, We’re about to set up Copilot Connectors for Azure DevOps (ADO) Wikis and Work Items across multiple organizations. During this process, we discovered that the account used to create the connector—requiring the Search Administrator role—is automatically designated as the crawl account. This crawl account must have read access across all projects within the ADO organization. Currently, we’re using our individual user accounts (with Search Administrator privileges) to create the connectors. However, we cannot use these accounts as crawl accounts due to access limitations. Ideally, the crawl account should be a service account with the necessary read permissions. The issue is that Microsoft’s configuration appears to require the same account to both create the connector and act as the crawl account. This would mean logging in with a service account that has Search Administrator rights, which is not a viable or secure option for us. Are we misunderstanding the setup? Is there a way to use our own accounts to create the connector and then specify a separate service account as the crawl account during configuration? We’re hoping someone can confirm that this separation is possible—and that we don’t need to grant Search Administrator privileges to a service account just to complete connector setup. Thanks - Grant.
Your interactive guide to setting up the web client via Direct Connect
Project Overview> I developed a way to use copilot studio agent using direct connect. This guide outlines how to configure a Microsoft Copilot Studio agent for secure web integration using Direct Connect, Azure Bot Services, and Power Platform. The web client uses a secure Express.js backend to handle credential exchange, ensuring the **Client Secret** is never exposed on the frontend. If anyone is interested, I can provide the source code. Prerequisites You must have administrative access to the following resources to complete the setup. 💻 Local Development Node.js (v12+) and Git installed. 🤖 Copilot Studio Agent Agent created and imported to the Production Environment. 🛡️ Azure Access Access to Azure Subscription 1 and Microsoft Entra ID for App Registration.Microsoft 365 Copilot Usage Report API General Availability
The Copilot usage report Graph API is now generally available. Like the report APIs for the other workloads, the Copilot usage API helps to understand usage of some very expensive licenses. Even better, the usage data can be combined with data from other Microsoft 365 sources to produce interesting and valuable insights. All it takes is some PowerShell to knit everything together. https://office365itpros.com/2025/10/10/copilot-usage-report-api-ga/Part 7: Copilot Pages × Teams — One Screen, No More Switching
Switching apps kills meetings. Silence. Dead air. Mistakes. The cure? One screen. Copilot Pages × Teams = Zero switching. Prepare, run, wrap — all in Pages. “Open once, close with confidence.” In Part 6, I proposed a “Feedback Dashboard” to connect users and Microsoft in continuous improvement. Now in Part 7, let’s face the toughest meeting problem: constant app switching. On the other side of the screen, nobody sees what’s happening — only waiting and broken focus. The solution is simple: don’t switch at all. Copilot Pages becomes the single cockpit for meetings: 1.Before — prepare everything in one Page. 2.During — dynamic sidebar and Teams control box. 3.After — results sync back automatically. Benefits • No more “Where’s the file?” moments. • No more dead air while someone fumbles with apps. • Teams and Pages finally feel like one seamless cockpit. In short: “Open Pages, run the meeting, close with confidence. No more switching.” Part One ends here — but my challenge to Microsoft is far from over. 第7弾：Copilot Pages × Teams ― アプリ切替ゼロの会議体験 会議を止めるのは、アプリ切替。 沈黙、待ち時間、ミス。 解決はシンプル。画面はひとつ。 Copilot Pages × Teams = 切替ゼロ。 準備も進行も振り返りも、Pagesで完結。 「沈黙ゼロ、切替ゼロ。Pagesを開けば、会議は止まらない。」 第6弾では「Feedback Dashboard」を提案し、ユーザーとMicrosoftが共に改善できる仕組みを描きました。 そして第7弾は、会議で最も深刻な問題に切り込みます。 アプリの切替による混乱とミス です。 参加者には見えない沈黙と待ち時間。 操作ミスが重なり、会議の流れが止まる。 解決策はただひとつ。切替をやめること。 Copilot Pagesを会議の“司令塔”にする： 会議前 ― 議題や資料をPagesに集約して準備。 会議中 ― 動的サイドバー（第3弾）と「Teams操作BOX」で進行を制御。 会議後 ― 成果は自動でTeamsチャネルに戻る。 効果 • 「ファイルどこ？」が消える。 • アプリ切替の沈黙がなくなる。 • TeamsとPagesが完全に融合し、ひとつの司令塔になる。 一言で言えば： 「沈黙ゼロ、切替ゼロ。Pagesを開けば、会議は止まらない。」 第1部はここで一区切り。 でも、Microsoftへの挑戦はまだ終わらない。Part 00 Extra: Criticism is Noise, Creation is Voice — See the People, Copilot Too
Recently, my Part 00 post was automatically hidden by the system. Even after revising the wording and reposting, it still didn’t appear — until I contacted support and they helped publish it. I felt disappointed and frustrated. Many posts online tend to be negative or complaint-based. But my intention was different. I’m someone who isn’t fully comfortable with digital tools. That’s exactly why I want to help create a world where older or less-experienced users can also shine in the digital era. It’s easy to filter by words. But when you try to describe the background, the problem, and the path to improvement, you’ll inevitably use words that may sound “negative.” If that alone stops voices from being heard, meaningful feedback disappears. In fact, this Extra chapter was originally planned to be posted earlier. However, Part 5 and Part 6 also got held in approval — a small “incident.” Before we turn voices into culture, those voices were stopped right at the entrance. Perhaps this, too, is a small design blind spot. The important thing is to judge not by words, but by people. That applies not only to Moderation, but also to the UX design of Copilot itself. Criticism is noise. Creation is voice. Turning these voices into culture — that’s what changes the future. This is not a complaint, but a question for building a better culture. I create with you. 👉 Next: Main Story, Part 7 — stay tuned. 00弾 外伝：批判はノイズ、創造は声 ― 人を見よ、Copilotも 先日、私が投稿した00弾が自動システムの判断で一時的に非公開になった。 言葉を見直して再投稿しても掲載されず、サポートに連絡してようやく公開された。 私は、残念で悔しかった。 確かに、多くの投稿は苦情やネガティブなものが多いのかもしれない。 しかし、私の声は違う。 私はデジタルに不慣れな立場だ。 だからこそ、年配者や初心者でもデジタル世界で輝ける世界を作りたいと願っている。 ワードで縛ることは簡単だ。 しかし、背景や問題点、改善点を語る文章には、どうしても“ネガティブに見える言葉”が含まれる。 それだけで声が届かないのでは、意味ある意見が消えてしまう。 実際、この外伝も本来はもっと早く投稿する予定だった。 ところが、第5弾と第6弾までもが承認待ちで止まる“小事件”が発生。 つまり、「声を文化にする」前に、文化の入口で声が止められるという、ちょっとしたパロディのような出来事になった。 これもまた、“設計の盲点”として受け止めたいと思う。 大事なのは、言葉ではなく人を見て判断することだ。 それはModerationだけでなく、CopilotのUX設計にも言えることだ。 批判はノイズ、創造は声。 この声を文化にすることこそが未来を変える力だ。 これは愚痴ではなく、文化をつくるための問いかけだ。 俺は、君たちと創る。 次回：本編第7弾。お楽しみに。
We need help solving a critical integration gap between Microsoft 365 Copilot and Salesforce.
The challenge: We want Copilot to access Salesforce data (including custom objects) while honoring each user’s Salesforce permissions—profiles, field‑level security, and sharing rules. Current out‑of‑box connectors don’t support this. Using an all‑access integration account is a compliance risk. Why it matters: Copilot is only valuable if answers are both accurate and secure. If a user sees data in Copilot they shouldn’t in Salesforce, that’s a governance nightmare. What we’re looking for: ✅ Support for custom objects & fields ✅ Enforcement of Salesforce profiles, FLS, and sharing ✅ Delegated user authentication (Entra ID ↔ Salesforce) ✅ Works with Microsoft 365 Copilot grounding Questions: - Has anyone implemented this successfully? - Is there a Microsoft or Salesforce roadmap for delegated auth in Copilot connectors? - Do you know a partner or expert who can build this securely? Let’s make Copilot + Salesforce both powerful and compliant.Using the Enterprise Website Microsoft 365 Copilot Connector
Microsoft 365 Copilot Search can be extended by ingesting information from external sources through a Microsoft 365 Copilot Connector. In this article, we show how to configure the Enterprise websites prebuilt connector to ingest articles from the Office365ITPros.com and Practical365.com sites, and how Copilot Search presents that information in its results and summaries. It’s quick, easy, and seamless – so really pretty good! https://office365itpros.com/2025/09/29/microsoft-365-copilot-connector/Microsoft Use of Anthropic AI Models Creates Concerns for Tenants
On September 24, Microsoft announced that Anthrophic LLMs could be used with the Copilot Researcher agent and to build agents with Copilot Studio. Although it’s great to enable choice so that customers can choose the AI model they prefer, questions about data security, lack of support for compliance solutions, and adherence to standards like the EU data boundary will concern Microsoft 365 tenants. https://office365itpros.com/2025/09/26/anthrophic-copilot/
