The Real ROI of Microsoft 365 Copilot Extensibility#

When does extending Microsoft 365 Copilot actually pay off? Here are my thoughts.

I’ve been consuming a lot of content around Microsoft 365 Copilot extensibility lately. And while the community is doing a great job producing tutorials, samples, and getting-started guides, I noticed something: there’s a ton of Hello World-style content out there, but very little about the actual return on investment. So I wanted to share my personal take on when extensibility is worth it — and what the real value looks like.

Are You Even Ready?#

Here’s the thing: many organizations I talk to are still in the middle of rolling out Microsoft 365 Copilot to their users. They’re figuring out adoption, licensing, governance — the basics. And that’s totally fine. But for these organizations, extensibility shouldn’t be the priority yet (even though the conference demos make it look like everyone should be building agents right now).

To me, the “extensibility moment” comes when you’ve reached a certain maturity. You’ve got a Copilot rollout going. Your users are actively working with it. You’ve identified use cases that work out of the box. And then — this is key — you start noticing the gaps. The moments where users need data or processes from third-party systems, LOB apps, or your ERP that Microsoft 365 Copilot simply can’t reach by default.

That’s when extensibility becomes relevant. Not because a demo looked cool, but because your users actually need it.

It’s About Personalization, Not Just Time Savings#

When people talk about ROI for extensibility, the conversation usually goes straight to time savings. “The agent saves 15 minutes per day.” And sure, that’s measurable. But to me, that misses the bigger picture.

The real value of Microsoft 365 Copilot extensibility is personalization. Out of the box, Microsoft 365 Copilot is a powerful but generic tool. It works the same for every organization. But it doesn’t know your ERP system. It doesn’t understand your specific business processes. It can’t interact with the industry-specific applications your people use every day.

Extensibility changes that. It transforms Microsoft 365 Copilot from a general-purpose assistant into something that understands and operates within your specific context. And that’s where the real productivity and efficiency boost comes from.

From Information to Delegation#

Let me make this concrete (because I think this example explains it best):

Without extensibility, a user asks Microsoft 365 Copilot: “How do I submit a purchase order in our ERP system?” — and Copilot tells them which screens to navigate and which fields to fill in. Useful? Yes. Better than a manual? Definitely.

With extensibility, the same user asks: “Submit a purchase order for 500 units of component X from supplier Y.” — and an agent connected to the ERP actually does it. Validates the request, triggers the process, confirms completion. The user didn’t get information about how to do their job. The agent did the job on their behalf.

That shift — from information to action, from assistance to delegation — is where the ROI becomes obvious. Not in minutes saved, but in entire process steps eliminated.

Start Small, Please#

One thing I’ve seen way too often: organizations approaching extensibility with too much ambition too early. They want an agent covering 20 processes across five systems on day one. And these projects tend to stall.

What works better (and I can’t stress this enough): start with an MVP. Pick one process. One integration. One use case where the current workflow is painful. Build something simple. Ship it. Learn. Iterate. Then expand.

Measuring What Actually Matters#

If you’re going to invest in extensibility, you should know whether it’s working. And “users like it” is not a metric. Here’s what I think you should be looking at:

Especially that last one is often overlooked. When a new hire needs to learn complex ERP processes, an agent that can guide or even execute these processes dramatically shortens the learning curve. That’s a powerful ROI argument.

So, What’s Your Extensibility Moment?#

I’m not saying every organization needs Microsoft 365 Copilot extensibility right now. Many don’t — yet. But I do think everyone should be actively thinking about it.

Look at your users’ daily workflows. Where do they leave Microsoft 365 to get things done? Where are processes slow or error-prone because the tools aren’t connected? Those are your extensibility opportunities.

Which processes in your organization do you think could get a real boost from Microsoft 365 Copilot extensibility?

The Citizen Developer Promise for Copilot Agents is an Illusion#

Low-code doesn’t mean low-complexity. Here’s where the line really is.

Microsoft has been telling a beautiful story: business users can describe what they want in natural language, and Agent Builder in Microsoft 365 Copilot will create an agent for them. When they outgrow the basics, they can seamlessly move to Copilot Studio with one click. No code required. Anyone can build an agent.

I’ve been watching this narrative evolve for over a year now, and I think it’s time for a reality check. The citizen developer promise for Copilot agents, as it’s currently marketed, is an illusion. Not a lie — an illusion. There’s an important difference.

The Happy Path Works Beautifully#

Let me be fair first. If you want to build a declarative agent that answers questions based on a curated set of SharePoint documents, Agent Builder does a genuinely impressive job. You describe the agent’s purpose, point it at your knowledge sources, maybe adjust the instructions, and you have something functional in minutes. For this specific use case — essentially a scoped Q&A bot over your own content — the citizen developer story absolutely holds up.

The problem starts the moment you need anything beyond that happy path.

Where Things Fall Apart#

The moment you need real integrations. Your HR manager wants an agent that doesn’t just answer questions about company policies but actually checks leave balances in Workday and submits time-off requests. That requires MCP server connections, authentication configuration, understanding OAuth flows, and dealing with connector infrastructure. I’ve watched technically savvy business analysts — people who are genuinely good with Power Automate and Power Apps — hit a wall when they try to configure MCP authentication with dynamic client registration. These aren’t concepts that a weekend workshop prepares you for.

The moment you need nuanced instructions. Agent instructions look simple — you’re just writing natural language, right? But crafting instructions that reliably produce the right behavior across edge cases is essentially prompt engineering. It requires understanding how the underlying model interprets ambiguity, how grounding works, what happens when the agent can’t find an answer, and how to handle multi-step reasoning. This is a skill that takes practice to develop, and most business users don’t have the feedback loops to develop it.

The moment you need to debug. Something isn’t working. The agent is returning wrong information, or it’s not calling the right MCP tool, or the authentication keeps failing. Where do you even start? Copilot Studio’s tracing and analytics have improved significantly, but interpreting activity maps, understanding tool invocation patterns, and diagnosing orchestration failures requires a developer mindset. There’s no low-code way to debug a complex agent.

The moment you need governance. Your citizen-developed agent works great in testing. Now it needs to go through the approval workflow in the admin center. IT needs to review the data sources, security needs to assess the permissions model, and compliance needs to verify the agent doesn’t expose sensitive data. The citizen developer built the agent — but they can’t shepherd it through enterprise governance alone.

The “Copy to Copilot Studio” Gap#

Microsoft’s answer to the complexity cliff is the “Copy to Copilot Studio” feature. Start simple in Agent Builder, then graduate to the full platform when you need more power. It sounds seamless, but it creates a handoff problem that nobody talks about.

The business user who built the prototype in Agent Builder understands the business logic. The developer who takes over in Copilot Studio understands the technology. Neither fully understands the other’s domain. The result is usually one of two things: the developer rebuilds from scratch (wasting the prototype work), or the developer tries to extend the existing agent without fully understanding the business intent (leading to subtle bugs that only surface in production).

This isn’t a new problem — it’s the same gap that has plagued every low-code-to-pro-code transition since the concept was invented. But it’s being presented as solved, and it isn’t.

What Would Actually Work#

I’m not arguing against democratizing agent development. I think it’s the right direction. But I think we need a more honest model of what citizen development looks like for agents:

Tier 1: Genuine citizen development. Q&A agents over curated content. Simple declarative agents with file-based knowledge. This is where business users can truly self-serve, and we should encourage it. But let’s be clear that this is the scope.

Tier 2: Guided development. Agents that need integrations, complex logic, or multi-step workflows. This requires a “buddy system” — a business user who understands the process working alongside a developer or a power user who understands the platform. Neither can do it alone effectively.

Tier 3: Professional development. Agents with custom MCP servers, complex authentication, multi-agent orchestration, or enterprise-scale governance requirements. This is developer territory, full stop. Pretending otherwise sets everyone up for frustration.

Invest in the middle tier. Most organizations focus on either the self-service story (Tier 1) or the pro-dev story (Tier 3) and completely ignore Tier 2. But Tier 2 is where the most valuable agents live — the ones that are specific enough to a business process to be truly useful, but complex enough to need some technical guidance.

Create feedback loops. The biggest gap in the citizen developer experience isn’t tooling — it’s learning. When a business user builds an agent that doesn’t work well, they rarely know why it doesn’t work well. Build internal communities of practice where people share what worked, what didn’t, and why. This accelerates learning far more than any tutorial.

Redefine success. If your measure of citizen developer success is “business users building production agents independently,” you’ll be disappointed. If your measure is “business users prototyping agent ideas that can be quickly validated and refined with technical support,” you’ll be much happier — and you’ll ship more useful agents.

The Bottom Line#

The tools Microsoft is building are genuinely impressive. Agent Builder, Copilot Studio, the MCP ecosystem — these are powerful platforms that lower the barrier to agent development significantly. But “lower the barrier” is not the same as “eliminate the barrier,” and the marketing often conflates the two.

The organizations that get the most value from Copilot agents won’t be the ones where everyone builds their own agents. They’ll be the ones that create the right collaboration model between business expertise and technical capability, with clear expectations about what each tier of development can realistically deliver.

Let’s stop selling the illusion and start building the support structures that make citizen-involved agent development actually work.

Have you tried building Copilot agents as a non-developer? Or are you a developer supporting citizen developers? I’d love to hear about your experience.

Microsoft 365 Copilot Extensibility: Navigating the Possibilities and Pitfalls#

As organizations rush to adopt Microsoft 365 Copilot, a critical question emerges: How do we extend Copilot to work with our unique business data and processes? The answer lies in understanding the three extensibility pillars—Connectors, Agents, and APIs—and knowing when (and when not) to use each. And that’s why I created an infographic for that:

Understanding the Anatomy of Microsoft 365 Copilot#

Before diving into extensibility, let’s understand what we’re extending. At its core, Microsoft 365 Copilot consists of:

The Core Engine#

• Orchestrator: The traffic controller that manages data governance, safety, and responsible AI (RAI) policies
• Foundation Models: The AI backbone powered by GPT-4o, GPT-4.1, and newer models like o1 and o3-mini

Where Extensibility Plugs In#

Copilot’s architecture exposes three key areas for extension:

The Three Extensibility Pillars#

1. Connectors: Bringing External Data to Copilot#

Direction: External Data → Copilot

Graph Connectors allow you to ingest and index external data into Microsoft Graph, making it available for Copilot to reason over.

What you get:

• 100+ prebuilt connectors for popular systems
• Custom connector development via Graph API
• Support for CRM, ERP, databases, and file systems

Best for:

• Making enterprise data searchable and available to Copilot
• Connecting line-of-business applications
• Enabling Copilot to answer questions about your proprietary data

⚠️ Pitfall: Connectors only provide read access. If you need Copilot to take actions in external systems, you’ll need Agents.

2. Agents: AI Assistants That Do Work#

Direction: AI Assistants ↔ M365 (Bidirectional)

Agents are specialized AI assistants that can automate workflows and perform tasks. They’re the most powerful—and most complex—extensibility option.

Inside Agents: Core Components#

Every agent consists of three parts:

1. Knowledge: Data sources like SharePoint, OneDrive, Graph Connectors, and web content
2. Instructions: Custom persona, tone, scope limits, and behavioral guardrails
3. Actions: Real-time API calls that let the agent do things

⚠️ Critical Insight: Actions ONLY work inside Agents! You cannot add actions to base Copilot—they must be wrapped in an agent.

Two Types of Agents#

Three Ways to Build Actions#

3. Copilot APIs: Embedding Copilot in Your Apps#

Direction: Your Apps → Copilot

Copilot APIs let you programmatically access Copilot’s capabilities from your own applications.

Available APIs:

Best for:

• Building custom applications that leverage Copilot
• Integrating AI capabilities into existing line-of-business apps
• Creating specialized user experiences

Common Pitfalls and How to Avoid Them#

Pitfall #1: Using Connectors When You Need Actions#

Symptom: “I connected my CRM data, but Copilot can’t create new records.”

Solution: Connectors are read-only. To write data back, create an Agent with Actions that call your CRM’s API.

Pitfall #2: Building Custom Engines When Declarative Would Suffice#

Symptom: Spending months building a custom AI engine for a simple Q&A bot.

Solution: Start with Declarative Agents. They deploy faster and Microsoft handles the AI infrastructure. Only go custom when you need specific models or complex orchestration.

Pitfall #3: Ignoring Data Governance#

Symptom: Copilot surfaces sensitive data to unauthorized users.

Solution: Connectors and Agents respect Microsoft 365 permissions. Ensure your data sources have proper access controls before connecting them.

Pitfall #4: Overlooking the Actions-in-Agents Requirement#

Symptom: “I built an OpenAPI action but can’t find it in Copilot.”

Solution: Actions must be deployed within an Agent. Create a Declarative Agent, add your action, and deploy the agent to Teams or M365.

Decision Framework: Choosing the Right Approach#

Do you need Copilot to access external data?
├── Yes → Use Graph Connectors
│   └── Do you also need to write back?
│       └── Yes → Add an Agent with Actions
└── No
    ↓
Do you need Copilot to perform tasks?
├── Yes → Build an Agent
│   ├── Simple tasks, quick deployment → Declarative Agent
│   └── Complex logic, custom AI → Custom Engine Agent
└── No
    ↓
Do you need AI in your own app?
├── Yes → Use Copilot APIs
└── No → You might not need extensibility!

Getting Started#

Tools You’ll Need#

Recommended Learning Path#

1. Start with Copilot Studio to understand agent concepts visually
2. Build a Declarative Agent with knowledge sources
3. Add an OpenAPI Action to perform a simple task
4. Explore MCP for more dynamic scenarios
5. Graduate to Custom Engine Agents when you hit limitations

Conclusion#

Microsoft 365 Copilot extensibility is powerful but requires understanding the architecture. Remember:

• Connectors bring data IN (read-only)
• Agents enable bidirectional interaction with Actions
• APIs let you bring Copilot OUT to your apps
• Actions only work inside Agents—this is the #1 gotcha

Start simple, validate your approach, and scale from there. The extensibility landscape is evolving rapidly, with MCP and new APIs in preview that will expand what’s possible.

Have questions about Copilot extensibility? The patterns and pitfalls shared here come from real-world implementation experience. Your mileage may vary, but understanding these fundamentals will set you on the right path.

Introduction#

Today we live in an era of constant change. Technology changes, mindset changes and vision changes. It started out with a bunch of Generative AI tools fueled by LLMs. These AI Tools now do not only offer the access to LLMs itself, but also give you the chance of creating and using agents. These agents give you two extra-assets:

• Consistency
• Scope

My friend Thomy wrote about the topic of AI Agents at Process Handovers: Where Consistency Matters More Than Intelligence , so if you want to know about why consistency matters, please read that first.

But with the introduction of agents, we also started shifting into an “Agent-Centric Workplace”. And I started to feel this myself rather quick: For every platform, for every service and for every use case, an agent could be built to assist me throughout my workday. To me, using agents goes beyond using Copilot. It’s more a concept of delegating work to my digital teammates = agents. And with all the recent announcements and udpates published by Microsoft around topics like autonomous agents, I do not think that this concept is going to vanish in the future. More likely, we will see the transition going from prompt-based assistants to goal/task-oriented, multi-step reasoning systems more and more over the course of the next weeks, months and years.

Ecosystem#

The Microsoft platforms offers a sophisticated ecosystem when it comes to building (and yes you may think why is he not writing “developing” instead of building, but we’ll come to that in a second) agents of many kinds. You can build agents in a variety of places with a variety of tools like:

• SharePoint
• Copilot Studio lite
• Copilot Studio full
• Microsoft Fabric
• M365 Agents Toolkit & SDK
• Azure AI Foundry
• Agent Framework
• …

And all of these platforms and frameworks target a specific agent builder audience, from low-code to pro-code. Eventually I will write another blog post, or even a series, about which platforms should be leveraged by which audience. But the good news here is, that there is at least one tool or platform for everyone, no matter which skills you have when it comes to building or developing an agent. And many of the agents built with these platforms can then be again consumed from one central place: Microsoft 365 Copilot. Therefore, the platform will likely evolve and governance aspects will also be covered more and more as more and more people will not only be using agents, but will also be building agents, either for their personal use, for their team or for the whole organization.

Multi-Agent Collaboration#

With the variety of tools and frameworks, the necessacity of introducing a concept called “Multi-Agent Collaboration” grew. Satya Nadella once said in a keynote of a big conference that “Copilot is the UI for AI”. Thinking about this message, I thought that this is the beginning of the Multi-Agent Collaboration era, where Microsoft 365 Copilot itself is also an agent, having the skills of orchestrating and collaborating with other agents.

But for me personally, hearing this message was not the first time for me personally to think of multi-agent scenarios. Looking back at my blog post on Microsoft Build 2019 updates on Conversational AI , the concept of Skills was introduced. And this to me was the first step towards a multi-agent collaboration era, because skills in the realm of the Microsoft Bot Framework where chatbots itself, which other chatbots would call to solve specific tasks.

Human-Agent Collaboration Patterns#

In the future, we might see a shift from “Copilot in apps” to “Copilot across work” as this may be something that people need more urgent. In my idea, I think an agent like a “Project Planning Agent” might be more helpful when integrated in all of my work apps, than an agent like the Copilot in Word. Because I want to perfectly do my project planning, which involves multiple platforms and services, so this agent should be accessible and integrated in all of the places where I do my work and is still specifically tailored to one specific goal (here we are again at consistency and scope).

This shit may also require us to rethink productivity rituals, like how do we manage meetings or how do we do reporting or how do we share knowledge when agents are our digital teammates, as they also need to be integrated into these rituals.

Future look#

With things like MCP, multimodal models and agents and the convergence of local and cloud intelligence, I do think that agents will play an important role in our future workplace. In the future we might not be talking “Copilot Adoption” but “Agent lifecycle management”, as I strongly believe that the introduction of “goal-oriented agents” will be a huge boost in the enterprise, to increas both our productivity as well as the quality we deliver our work with. Therefore I encourage everyone reading this, to experiment with agents and especially with multi-agent scenarios as this will likely hit us sooner or later and furthermore, think about this: “What’s your vision for the agentic workplace?” and let me know what’s your opinion!

Introduction#

Microsoft is pushing the boundaries of how business processes can be automated with its Copilot Studio—a cloud-based, low-code platform that empowers organizations to build AI agents. In its latest release, Microsoft has introduced autonomous agent capabilities aimed at enabling agents to proactively respond to events, orchestrate tasks, and integrate seamlessly with enterprise data sources. However, while these functionalities open exciting prospects, in my opinion, they currently feel quite basic—likely reflecting their preview status.

Autonomous Agent Capabilities at a Glance#

With Copilot Studio, Microsoft now provides tools to build autonomous agents that can:

• Monitor & React: Automatically respond to business signals or triggers to initiate tasks.
• Execute Business Processes: Leverage AI orchestration to run rule-based workflows and automate repetitive tasks.
• Integrate with Data Sources: Connect to Microsoft Graph, Dataverse, and other connectors to pull in context.
• Enhance Productivity: Offer a low-code way for teams to extend Microsoft 365 Copilot with personalized AI agents.

Fundamental Architecture Diagram#

A core element of understanding autonomous agents in Copilot Studio is their underlying architecture. Below is a diagram which displays a visual representation of the system:

Figure 1: Fundamental Architecture for Autonomous Agents in Microsoft Copilot Studio

This diagram illustrates how user interactions are processed through Copilot Studio, which utilizes an orchestration engine to understand the trigger and inputs along with building and executing a plan. The agents then access context-rich data from secure sources to generate responses.

The Preview Nature: Opportunities and Limitations#

While the preview release is promising, the current autonomous agent capabilities appear somewhat basic:

• Limited Customization: The workflow options and decision-making granularity are still evolving.
• Early-Stage Integrations: Integrations with external systems work at a basic level—expect enhancements with additional connectors and refinements.
• Dependence on User Feedback: Early adopters find that while the automation framework offers efficiencies, further adjustments and human oversight are needed to handle complex real-world scenarios.

These observations suggest that the preview is an important first step, setting the stage for further refinements as Microsoft iterates based on customer feedback.

Looking Ahead#

Microsoft’s vision for transforming business processes with AI is clear. As additional features and deeper integrations are developed, we can expect:

• More advanced decision-making capabilities.
• Enhanced automation for complex workflows.
• Greater interoperability across the Microsoft ecosystem.

Even though the functionality now might seem basic, it represents a foundational step towards a future where AI agents can autonomously handle a wide array of business tasks with minimal human intervention.

What do you think about the current state of autonomous agent capabilities in Copilot Studio? Do you see this basic functionality as laying the groundwork for a more advanced, fully autonomous future?

Setup#

You obviously need to create or already have an agent in Microsoft Copilot Studio. If you don’t have an agent already follow this tutorial to create a new custom engine agent in Copilot Studio.

After you have created an agent go to your settings page of the agent and then under “Generative AI” you can enable the checkmark on “Use deep reasoning models”:

When you now send a prompt to your agent you should see that the agent is using deep reasoning to generate the answer:

What’s interesting is that you can also see what the agent does take into account when doing the reasoning:

As you can now also add your custom engine agents built with Copilot Studio to your Microsoft 365 Copilot you can use this method to add deep reasoning to Microsoft 365 Copilot:

Considerations#

This feature is currently in preview so be careful when to enable this (maybe not the best idea to use this for all production agents already). Another requirement is that your agent needs to be created in a US-based Power Platform environment and the agent’s language should be English, otherwise you’ll see the setting, but the agent will not use deep reasoning unfortunately.

Agent Instructor#

Agent Instructor is a powerful Visual Studio Code extension designed to help developers create, analyze, and refine instructions for declarative AI agents. This tool is essential for ensuring clarity and effectiveness in agent instructions, making it easier to build robust AI solutions.

Key Features:#

Analyze Instructions:

• Clarity Score: Evaluates existing instructions and provides a clarity score (0-100).
• Ambiguity Detection: Identifies ambiguous phrases and offers specific improvement suggestions.
• One-Click Corrections: Allows users to apply suggested improvements with a single click.
• Visual Analysis: Displays analysis results with intuitive charts.

Generate Instructions:

• Interactive Input: Facilitates the creation of comprehensive instructions through interactive agent description input.
• AI-Powered Generation: Automatically generates well-structured and formatted instructions.

Installation#

Head over to the VS Code Marketplace to install the extension from there or search for “Agent Instructor” in the VS Code extension store. Feel free to leave feedback as I’m interested in your opinion!

Introduction#

As of now, there are a lot of options for building agents for Microsoft 365 Copilot and related services. If you are a heavy SharePoint user you can build agents which are grounded into your SharePoint knowledge with only a few clicks right within the SharePoint UI. If you are a low code maker, you can use either the Copilot Agent Builder or Microsoft Copilot Studio to build declarative agents which can then be surfaced through the Microsoft 365 Copilot Chat UX or Microsoft Teams. And if you are a pro developer you can build either declarative agents using Teams Toolkit for Visual Studio Code or Visual Studio or you can build a custom engine agent using whatever tech stack you like. That may range from integration services such as the Teams AI Library to the Microsoft 365 Agents SDK to Azure AI Foundry or any other API you may want to consume.

As there are many options for building agents, I tried to visualize all of them into one single infographic:

Conclusion#

As the infographic shows, you have a lot of options to choose from when it comes to building agents for Microsoft 365 Copilot. Feel free to use it for internal use in your presentations or documents. The only point I ask you to do is to credit me and link this article to your documents where you use it. Please do not sell this as your own 😉

Introduction#

In early 2024 I released the first version of the Microsoft 365 Copilot extensiblilty options guide . Since then a lot has changed, especially the fact that Microsoft announced a at Build the capability of not only building Connectors and Plugins, but also Agents . This path was further strengthened with the Microsoft 365 Copilot Wave 2 announcements in September 2024. Despite many other updates and announcements like Copilot Pages and others, the agentic capabilities within Copilot is one of the biggest updates which lets developers not only extend Copilot using plugins or connectors, but now you can build declarative agents which combine plugins and connectors into one single solution which can then be used either seperately or within the Microsoft 365 Copilot experiences.

As there where many updates and changes, I modified the initial version of my decision guide, which can be found in the following infographic:

Conclusion#

As the infographic shows, you have a lot of options to choose from when it comes to finding the suitable approach for extending Microsoft 365 Copilot. And when the Agent Builder functionality is rolled out, I will certainly add this to that infographic as well.

Feel free to use it for internal use in your presentations or documents. The only point I ask you to do is to credit me and link this article to your documents where you use it. Please do not sell this as your own 😉

Introduction#

In this post, we will delve into the hidden prerequisites and requirements for using Copilot for Microsoft 365. We aim to provide a comprehensive guide that will help you understand what you need to get started and ensure a smooth operation of Copilot within your Microsoft 365 environment. Let’s uncover these hidden prerequisites together.

Copilot requirements#

The requirements and prerequisites for Copilot for Microsoft 365 are very well documented here . Of course I asked Copilot to generate a list of requirements, so here it is:

• Base License: Users need a prerequisite base license, detailed in the service description guide.
• Microsoft 365 Apps: Deployment of Microsoft 365 Apps is necessary.
• Third-party Cookies: For online versions of Word, Excel, and PowerPoint, third-party cookies must be enabled.
• Privacy Settings: Review Microsoft 365 Apps privacy settings as they affect Copilot features.
• Microsoft Entra ID: Users require Microsoft Entra ID accounts, which can be added or synced via the admin center.
• OneDrive Account: Certain features like file restore need users to have a OneDrive account.
• Outlook: Copilot works with the new Outlook in preview, and settings sync is required for integratio5.
• Teams: Configuration of Teams settings is essential for Copilot functionality in Teams.
• Teams Phone: For referencing meeting content, transcription or recording needs to be enabled.
• Microsoft Loop & Whiteboard: Enablement of Loop and Whiteboard for tenant use is required.
• Update Channels: Copilot is supported in all update channels, except for Semi-Annual Enterprise Channel.
• Network Connectivity: Aligning with Microsoft 365 network connectivity principles is recommended.
• WebSocket Connections: Allow WebSocket connections for Copilot experiences that require them.

In terms of licensing, Copilot for Microsoft 365 is available as an add-on plan with one of the following licensing prerequisites:

• Microsoft 365 E5
• Microsoft 365 E3
• Office 365 E3
• Office 365 E5
• Microsoft 365 Business Standard
• Microsoft 365 Business Premium
• Microsoft 365 A5 for faculty
• Microsoft 365 A3 for faculty
• Office 365 A5 for faculty Please note that these requirements are nearly identical to the requirements for using Microsoft 365 Apps due to the integration of Microsoft Copilot for Microsoft 365 and Microsoft 365 Apps.

But the list of requirements was missing one crucial thing: Enablement of the Office Feature Updates task from the scheduled tasks on the Windows client. If the execution of the following 2 tasks is blocked, then Copilot will not work on the client and in the local versions of the Office apps:

• Office Feature Updates
• Office Feature Updates Logon

Conclusion#

Make sure to check out the Copilot requirements from time to time to see if anything has changed. Shout-out to my colleague Gottfried Jocham, for detecting the need for the scheduled task.