Microsoft 365 Copilot Extensions and Integrations

What Copilot can and cannot see without extensions

Out of the box, Microsoft 365 Copilot works over content in Microsoft Graph: the email, files, chats, meetings and SharePoint sites each user already has access to. That is useful for summarizing a thread or drafting a document, but it stops at the edge of Microsoft 365. Ask it about an open order, a warranty claim, a job’s status or a customer’s contract terms, and it has nothing to go on unless those live in a Word file somewhere.

For most companies the important records sit elsewhere: an ERP such as NetSuite or Dynamics 365, a ticketing system, a CRM, a homegrown SQL application or a vendor portal. Extensions are how those systems become part of Copilot’s answers and actions.

Tepia’s job is to decide which of those systems are worth connecting, in what form, and with what permissions. Connecting everything at once creates noise and risk. Connecting the two systems your teams ask about every day changes how Copilot is used.

The Copilot extension options, compared

Microsoft offers several ways to extend Copilot, and they solve different problems. Tepia usually combines two or three in one project:

The rule of thumb: connectors for reading, plugins for live data and actions, declarative agents to package both for a specific team. Our comparison of Copilot Studio vs a custom chatbot covers the low code route in more depth.

Example: bringing an order system into Copilot

Consider a distributor whose customer service team handles orders in a custom SQL application and answers questions from a shared inbox. Tepia would scope three pieces.

• A Copilot connector that indexes the product catalog, shipping policies and return rules, each item tagged with the groups allowed to read it.
• An API plugin over a small, purpose built API with three operations: look up an order, check stock for a SKU, and start a return. The return operation asks the user to confirm before anything is written.
• A declarative agent called Order Desk, available only to the customer service group, with instructions to cite the order number and policy section in every answer.

A representative types a customer’s question into Teams, and Order Desk replies with the order’s current status, the relevant return rule and a draft reply, all inside the tools they already use. Tepia builds the API layer itself when the legacy application has none, which is common. Our API development and integration team handles that part.

How Tepia approaches Copilot extensions

Tepia runs its six phase process with your Microsoft 365 administrators involved from the start, since they approve and deploy every extension. A US based project manager owns the plan.

1. Discovery: interviews with the teams who will use Copilot, a review of the line of business systems and their APIs, and a check of your tenant’s licensing and admin policies. Deliverables are an Investigation Summary, an Interview Summary and User Stories such as a rep checking an order from Teams.
2. Design: extension architecture, agent instructions, conversation starters, adaptive card layouts for results, and the confirmation steps for any write action.
3. Development and Testing: connectors, APIs and OpenAPI descriptions, agent manifests and permission tests. Alpha runs in a development tenant; Beta goes to a pilot group in production.
4. Training: short sessions by role on what each agent can do and how to phrase requests, plus admin training on updates.
5. Launch: staged deployment through the Microsoft 365 admin center, usage monitoring and support reps on call for the pilot group.
6. Support: new actions, connector schema changes and updates as Microsoft revises the extensibility platform.

Copilot extension projects often have shorter Discovery than a full app because the interface already exists, but typical ranges still apply: 1 to 3 months for Discovery and 2 to 6 months for development and QA. See our process.

Security, permissions and admin rollout

The first question from IT is always whether Copilot will expose data people should not see. Tepia designs every extension so it cannot widen access.

• Connector items carry access control lists mapped from the source system to Entra ID users and groups.
• API plugins use OAuth with delegated permissions, so the API sees the actual employee and applies its own rules.
• Scopes are kept to the minimum each action needs, and write actions require explicit confirmation.
• Sensitivity labels from Microsoft Purview are respected for content that flows through Graph.
• Logging records every API call an agent makes, for audit and troubleshooting.

Tepia also helps admins plan rollout: which groups see which agents, how updates are approved, and how to retire an agent cleanly. Single sign on details are covered on our SSO and identity integration page.

A Copilot extension or a separate custom AI app?

A Copilot extension is the right choice when your users are employees who already work in Teams and Outlook, already hold Copilot licenses, and need answers or actions tied to internal systems. Tepia will recommend it over a standalone app in that case, because adoption is easier when nothing new has to be installed.

A separate application fits better when the users are customers, field staff without Microsoft 365 accounts, or anyone on a mobile app you control, or when you need a model, interface or data residency that Copilot does not offer. Many companies end up with both: a Copilot agent for staff and an Azure OpenAI powered assistant in their customer app, sharing the same APIs. If Dynamics 365 is part of the picture, see Microsoft Dynamics integration, then talk to Tepia about which systems to connect first.

Frequently asked questions