AI Architecture & Integration · Microsoft 365
Extending Microsoft 365 Copilot: How and Why
Microsoft 365 Copilot knows the emails, chats and documents in Microsoft 365. Many workflows, though, depend on ERP, CRM, ticketing or custom systems. Agents and Copilot connectors link Copilot to that data and those processes. This overview shows which option fits when.
Julia Rose
Key takeaways
- Copilot can be extended in three ways: with agents, with actions that call external systems, and with Microsoft 365 Copilot connectors for enterprise data.
- Declarative agents use Copilot’s own orchestrator and models. Custom engine agents bring their own orchestration and models.
- Copilot connectors, formerly Microsoft Graph connectors, bring data from external systems into Copilot, synced or in real time via MCP.
- More than 100 prebuilt connectors already exist, for example for Confluence, Salesforce and ServiceNow.
Why extend Copilot?
Microsoft 365 Copilot works with the content users can access in Microsoft 365: emails, chats, meetings and documents in SharePoint and OneDrive. In daily work, though, important information also lives elsewhere, in ERP, CRM, knowledge bases or ticketing systems. And many tasks end with a next step in a specialist system.
Extensions close that gap. Copilot can then answer questions about orders, tickets or product data and trigger actions, such as updating a record.
Three ways to extend Copilot
| Option | What it does |
|---|---|
| Copilot connectors | Bring data from external systems into Copilot so users can search and work with it. |
| Declarative agents | Configure Copilot for a scenario with custom instructions, knowledge and actions, using Copilot’s orchestrator and models. |
| Custom engine agents | Own orchestration and own models for complex workflows, running in Microsoft 365 and, if needed, outside it. |
Source: Microsoft Learn, Extend Microsoft 365 Copilot
Connecting enterprise data: Copilot connectors
Microsoft 365 Copilot connectors, formerly called Microsoft Graph connectors, come in two models:
- Synced connectors ingest content into Microsoft Graph and index it semantically. They suit knowledge bases, document stores and line-of-business applications.
- Federated connectors retrieve content at query time via the Model Context Protocol (MCP) without storing it in Microsoft Graph. They suit fast-changing data or content that must stay in the source system.
Prebuilt connectors exist for many common systems, more than 100 according to Microsoft, for example Confluence, Salesforce and ServiceNow. For your own systems, a synced connector is built in three steps: create a connection, define a schema, ingest content. For Copilot to use the content well, meaningful titles, content-rich text and the access permissions of each item matter.
Source: Microsoft Learn, Microsoft 365 Copilot connectors overview
Automating tasks: agents
With agents, Copilot gains knowledge and actions for a specific area, such as an IT helpdesk or order lookups.
- Declarative agents consist of custom instructions, custom knowledge (SharePoint, OneDrive, Teams, Copilot connectors) and actions that call external systems through APIs. They run on Copilot’s infrastructure, need no separate hosting and can be built with low-code tools or with the Microsoft 365 Agents Toolkit.
- Custom engine agents are fully custom assistants with their own orchestration and a free choice of models. They suit complex business rules, several connected systems, proactive workflows or use outside Microsoft 365. They need their own hosting, for example in Azure, and security and compliance are your responsibility. They are built with Copilot Studio or in code, for example with Semantic Kernel or LangChain.
Source: Microsoft Learn, Agents for Microsoft 365 Copilot
Which option fits?
- Is Copilot only missing data? Then a Copilot connector, prebuilt or custom, is often enough.
- Should Copilot cover a scenario with fixed instructions and a few actions? Then a declarative agent fits.
- Does the workflow need its own rules, several systems, its own models, or should it start without a user request? Then a custom engine agent is the right path.
Whichever option you choose, check permissions, data storage and licence and hosting costs before the first extension goes live.
The first step: enabling teams
Extensions only pay off once employees use Copilot confidently in their daily work. That is why many companies start with a workshop.
In practice: GS1 Poland and a real estate company
At GS1 Poland, together with Apollogic, we introduced employees from several departments to Microsoft 365 Copilot in Word, Excel, Teams and Outlook, working on their own tasks. For a real estate company, marketing, legal, technical and operations teams built their own GPT assistants for their bottlenecks in a full-day workshop.
Read the GS1 Poland case study · Read the real estate case study
How AI can also be integrated into SAP, Microsoft 365 and Jira is covered in our article The model is rarely the problem.
Connecting Copilot to your systems?
We work out with you whether a connector, an agent or a custom solution fits, and how your teams use Copilot in daily work.
Request a process analysisFrequently asked questions
Through Microsoft 365 Copilot connectors, which bring in data from external systems, and through agents: declarative agents with custom instructions, knowledge and actions, or custom engine agents with their own orchestration and models.
They were formerly called Microsoft Graph connectors. They bring data from external systems into Copilot, either synced into Microsoft Graph or in real time via the Model Context Protocol without storing the data.
Declarative agents use Copilot’s orchestrator and models and need no separate hosting. Custom engine agents have their own orchestration and models, need their own hosting and suit complex workflows.
Low-code tools such as Copilot Studio, or code, for example with the Microsoft 365 Agents Toolkit in Visual Studio or Visual Studio Code.
Julia has been part of theBlue.ai since 2019 and has accompanied the development of AI applications in the enterprise environment since the company’s early days. In her role as Marketing Lead, she works closely with the engineering and consulting teams and makes complex technical topics understandable and accessible for decision-makers.
In her articles, she writes about practical experience from enterprise AI projects, as well as the challenges and opportunities of using AI in companies.