Microsoft 365 Copilot Integrations That Actually Ship to Production

The Copilot extension landscape, in 2026

Microsoft 365 Copilot has matured into a real enterprise platform. As of mid-2026, there are five distinct extension patterns, each with its own review process, SDK, and deployment model. Picking the right one is the difference between a 4-week ship and a 6-month saga.

The five patterns

• Declarative agents — JSON-defined agents with custom instructions, knowledge sources, and actions. The simplest extension. Best for >70% of use cases.

• Message extension plugins — Adaptive cards that surface external data in Copilot chat. Best for “search our system from Copilot” use cases.

• Graph connectors — Ingest external data into the Microsoft Graph, making it searchable and RAG-able by Copilot. Best for “Copilot should know about our internal docs” use cases.

• Custom engine agents — Full SDK, you own the orchestration. Best for complex multi-step workflows.

• Connectors for Power Platform — Low-code, for citizen developers. Best for departmental tools.

Most production engagements ship declarative agents + Graph connectors. That’s what this article focuses on.

Declarative agents: the 80% solution

A declarative agent is a JSON file that defines:

• Name, description, icon — the agent’s identity in the Copilot UI

• Instructions — system prompt, written in natural language

• Conversation starters — suggested prompts users see when they open the agent

• Knowledge sources — SharePoint sites, Graph connectors, public URLs, uploaded files

• Actions — API plugins the agent can call (defined as OpenAPI 3 specs)

That’s it. No code, no infrastructure, no SDK to learn. You write a JSON file, package it as an app manifest, submit to the Microsoft admin center, and your agent appears in the Copilot UI for your tenant.

The 200-line agent that solved a Fortune 500 helpdesk

Real example: a helpdesk agent for a 4,000-employee company. The agent could:

• Search the internal knowledge base (via Graph connector)

• Look up ticket status (via API action calling ServiceNow)

• Create a new ticket (via API action)

• Escalate to a human (via API action opening a Teams chat)

The entire agent definition was 217 lines of JSON. The two API actions were 84 lines of OpenAPI each. Total: ~400 lines. Shipped in 3 weeks. Cleared the security review on first submission.

Graph connectors: making your internal data Copilot-aware

A Graph connector ingests external data into the Microsoft Graph, where Copilot can use it for RAG. You define:

• The data source (database, API, file share, CMS)

• The schema (what fields exist)

• The refresh cadence (every 15 minutes, every hour, etc.)

• The access permissions (which Entra ID groups can see which content)

Once ingested, the data is available to Copilot in every experience — Word, Outlook, Teams, the chat — and to your declarative agents.

The access-control gotcha

Graph connectors respect the access permissions you set. If user A doesn’t have permission to see a document, Copilot won’t surface it for user A. This is correct behavior, but it surprises teams who expect Copilot to “just know everything.”

The fix: design your access model with Copilot in mind. The same model that gates document visibility in SharePoint gates what Copilot can say. Test with a low-permission user account.

The security review: how to pass on the first try

Microsoft’s tenant-side security review is the most common blocker. Teams that get it wrong lose 2-3 months in resubmission cycles.

Five things that get you rejected

• Overly broad API permissions. Requesting Files.ReadWrite.All when you need Files.Read.Selected. Always use the most specific permission.

• No data handling disclosure. You must declare where data is processed, stored, and whether it leaves the tenant.

• Unauthenticated API actions. Every action endpoint needs OAuth 2.0 with a registered Entra ID app.

• Missing admin consent flow. The agent must be deployable via the admin center with a clear consent screen.

• Stale or unmaintained manifest. Microsoft reviews reject agents that haven’t been updated in 6+ months.

The review checklist we use

• All API actions use specific permissions (not *.All)

• Data handling disclosure names the geography, retention, and deletion policy

• OAuth flow is documented with a runnable demo

• Admin consent screen is screenshotted and attached

• Manifest is versioned with a changelog

• Update cadence is declared in the manifest (e.g. “updated quarterly”)

With this checklist, our pass rate on first submission is 9 out of 10.

Architecture patterns we ship

Three common Copilot integration patterns we deploy for clients:

1. Knowledge worker augmentation

Graph connector + declarative agent. Ingest internal docs (SharePoint, Confluence, Notion, internal wikis) into Graph, build an agent that answers questions in natural language. No code, just configuration. 2-3 week engagement.

2. Process automation

Declarative agent + multiple API actions. The agent handles a multi-step business process (expense approval, ticket routing, contract review). 4-8 week engagement. Requires custom backend or Power Automate flow.

3. Custom engine agent for complex workflows

Full SDK, custom orchestration, custom LLM (often Azure OpenAI). For use cases that don’t fit the declarative pattern — multi-agent systems, complex RAG over heterogeneous sources, integrations with non-Microsoft systems. 8-16 week engagement.