Copilot Integration Architecture: When Out-of-Box Copilot Stops Being Enough

By Michael Branson | August 26, 2026

The complaint arrives in familiar words. Licences were bought, the rollout went fine, and then somebody in claims processing or contract administration said the sentence that starts the project: Copilot cannot see our data. It answers questions about last quarter’s deck and knows nothing about the policy engine, the case management system, or the twelve-year-old scheduling database that three departments actually run on.

Quick answer. Copilot integration architecture decides which of four paths a use case needs: out-of-box grounding, Copilot connectors, declarative agents, or custom engine agents. Each path after the first assumes the reach earlier ones supply, so readiness sets the sequence and decides which path a use case can reach.

The complaint is accurate about the symptom and misleading about the cause. The vendor’s own Microsoft Copilot overview describes what the product reasons over: “Microsoft Graph brings a personalized organizational data context into the prompt, like information from a user’s emails, files, meetings, calendars, teams, or organizational relationships”, and the same page lists “Access scoped by user permissions (security and compliance enforced)” among the things that power every Copilot experience. So a system whose content never reaches Microsoft Graph is invisible to out-of-box Copilot by design, and no amount of prompt work changes that. Something has to carry the content across, or carry the question out.

What follows is the decision about which something, and in what order. The order is the substance here. Four paths exist, each one after the first assumes the reach earlier ones supply, and a use case that reaches for the fourth while the first is still broken buys a longer version of the same complaint. This page is about the sequence and the preconditions. It is not about how a Copilot Studio agent gets built, what an AI governance model contains, or which tenant gates precede a first-party Copilot rollout, and each of those has a page that owns it.

What This Page Decides, and What the Other Pages Own

Five boundaries, because this decision sits next to several that are not it.

If Copilot is not deployed yet, or is deployed and the tenant work behind it is unfinished, the sequence runs the other way and the first work is readiness. That is covered in full at Is Your Microsoft Environment Ready for Copilot? What Must Be True First, which sets out the licensing, identity, oversharing, labelling, semantic index and ownership gates that come before any of this. That page is about what has to be true in the tenant. This one is about what has to be true about a use case before an integration path is available to it.

Governance is a separate object. What an enterprise AI governance model covers, meaning data boundaries, usage policy, identity, monitoring and named accountability across Microsoft 365, Azure and Power Platform, is worked at Enterprise AI Governance for Microsoft Environments. The agent-specific half of that frame, meaning what a single agent is allowed to reach, who authorizes an action, whose identity it runs under, what a release test proves, and when it retires, belongs to a forthcoming guide, Copilot Studio Governance. This page names a path and its preconditions; it does not write policy for either.

That build is sold and described at Microsoft Copilot Studio Development Services for Enterprise-Grade Custom Copilots. Architecture, environments, testing and deployment all live there. Nothing on this page is a build method, and the two pages answer different questions: that one answers who builds it and how, this one answers whether the use case has earned that path yet.

Where a solution spans Power Platform and Azure, the interior of that split is its own decision, and it is treated at Power Apps and Azure: The Hybrid Architecture Boundary. This page hands the hybrid interior off at the point where a Copilot use case needs a service, a job or a data store that a maker platform will not hold.

The fifth reorders the whole plan wherever it applies. Cleaning up who can see what inside the Microsoft 365 tenant is a separate programme from connecting anything new, and it is worked at The Copilot Data Governance Fix. The data question on this page is the other side of the same coin: what has to be true about a source that is not in the tenant yet.

All of these decisions sit inside the practice at Custom AI Consulting Services for Governed Microsoft Enterprise AI.

The Four Paths, and What Each One Assumes

The vocabulary is worth getting exact, because two of these four are routinely called by the other’s name in the same meeting.

Out-of-box grounding is Copilot reasoning over what Microsoft Graph already holds. That reach belongs to the Microsoft 365 Copilot Premium license; Microsoft states plainly that Copilot Chat Basic and Microsoft 365 Copilot Basic “can’t use organizational data via Microsoft Graph when interacting with Copilot Chat”, so a reader on either Basic license does not get this path without uploading the content, working with open content in Teams or Outlook, or using a pay-as-you-go agent. The Microsoft Copilot overview describes that scope as the organizational data Copilot grounds its responses in, emails, files, meetings, calendars, teams and organizational relationships, reached through Microsoft Graph and scoped by each user’s permissions. Nothing is built and nothing is connected. The assumption underneath it is that the answer the user wants is already inside content the tenant holds and the user is allowed to open. There is also a named switch that can make this path look broken when the content is in fact present, and the same overview page records it: Work IQ, “an intelligence layer that enables agents access to reason over organizational data, content and tools”, carries the note “You can turn Work IQ on or off”, and the documented consequence of off is stated plainly, “When Work IQ is off, Copilot responses aren’t grounded in Microsoft Graph and Work IQ.” So before a source is declared unreachable, it is worth establishing that the grounding layer is on.

Copilot connectors are the mechanism that widens what Microsoft Graph holds. Microsoft’s Copilot connectors overview states the purpose: they “extend the reach of Microsoft 365 Copilot and Microsoft Search experiences by connecting to data beyond Microsoft 365”. The same page records two shapes with a real difference between them, and the choice belongs to the source rather than to the use case: “Your organization can either index external data by using synced connectors or connect to data in real time by using federated connectors”. A synced connector “uses the Microsoft Graph connectors API to ingest items into the Microsoft Graph index”, and each ingested item “includes content, metadata (like title and URL), and an access control list (ACL) that enforces permissions”. A federated connector leaves the content where it is. The assumption underneath both is that the answer exists as findable content somewhere, and that the source system can say who is allowed to read each piece of it.

Declarative agents are Copilot pointed at a job. Microsoft’s guidance on Declarative agents for Microsoft 365 Copilot describes the parts: “When you build a declarative agent, you provide the instructions, actions, and knowledge to tailor Copilot for your business scenarios.” The knowledge is the estate the agent is allowed to read, and the same page records that declarative agents “can also use enterprise data from SharePoint, OneDrive, Copilot connectors, and uploaded files”. The actions are how the agent reaches a system it cannot read its way into: “Enterprises can extend declarative agents by using plugins to retrieve data and run tasks on external systems.” The assumption underneath is that the knowledge the agent needs is already reachable, because an agent’s knowledge shapes and directs access it has been given, and it is the agent’s actions, not its knowledge, that reach a system it cannot read.

Custom engine agents are the path where you supply the machinery. Microsoft’s Agents for Microsoft 365 Copilot sets the two approaches against each other in one sentence: “You can use one of two approaches to build agents for Copilot: the declarative approach, which utilizes your instructions, knowledge, and actions along with Copilot’s orchestrator and models, or the custom engine approach, where you bring your own orchestrator and models to create a fully tailored agent.” The consequences are stated on the same page and they are the reason this is the last path rather than the best one. On hosting, declarative agents “Use Copilot’s orchestrator and foundation model. No additional hosting is required”, while custom engine agents “Require additional hosting outside of Microsoft 365, typically with cloud services such as Azure, at an additional cost”. On compliance and security, a declarative agent “Inherits Microsoft 365 compliance, RAI, and security standards”, where the custom engine row puts your own compliance, RAI practices and security measures on your organization.

Two things follow from reading those four together, and they are what make this a sequence instead of a menu.

One is that each path after the first inherits the dependencies of the reach it is built on. A declarative agent that draws on a synced Copilot connector is only as good as that connector’s index, and that index is only as good as the source system’s own permission model, because the ACL the connector ingests is the source’s. A federated connector has no index, so the same dependency sits on the source’s own permission check at query time. So a permission problem in a line-of-business database does not stay in the database once a connector indexes it. It becomes an answer in a chat window.

The second is that the paths get more capable and less inherited as you go. Out-of-box grounding and Copilot connectors keep the platform’s own controls. The last two add behaviour, and the fourth adds behaviour by taking the platform’s controls off and handing you the obligation, which the compliance row above states in the vendor’s own words. That is a real trade and it is worth making deliberately, once, at the top of a project.

The Test That Says Out-of-Box Has Stopped Being Enough

Three questions decide it, and they are asked in this order: the knowledge question, the action question, and the audience question.

The knowledge question is where the answer lives. If the content that answers the user’s question is already in mail, files, meetings or chats, the knowledge question passes, and out-of-box grounding is the whole job unless the action or audience question says otherwise. If the answer lives in a system Microsoft Graph does not hold, the knowledge question has failed and a connector is the smallest thing that fixes it. This is the question the opening complaint names, and it is the one a project skips when it starts from the agent instead of from the failure.

Whether anything has to change is the action question. A connector makes content findable. It does not make anything happen. Microsoft states the limit on the federated shape without qualification: “Federated connectors are read-only; they can search and fetch content but can’t write data back.” A use case that has to create the ticket, update the record or start the approval has an action requirement, and actions arrive with agents and plugins, since a connector’s job ends at making content findable.

The audience question is who is asking and where. A single team asking a narrow set of questions inside Copilot chat is a declarative agent’s shape. A workflow that has to start without a person typing anything is not, and Microsoft’s comparison table says so directly: on proactive interactions, declarative agents are “Not supported; rely on user-initiated interactions”, where custom engine agents “Enable agents to trigger actions automatically, even without direct user input”.

When two of these three point at different paths, the action question outranks the other two. The reason is mechanical rather than a preference: a knowledge gap has two available fixes, a synced connector or a federated one, and either can be added later to a use case already running on out-of-box grounding. An action requirement has no equivalent, because the federated shape is documented read-only and the synced shape writes into the Microsoft Graph index instead of into the source. So a use case that fails the knowledge question and the action question at once is an agent question that also needs a connector wherever the source can be indexed, and it is scoped as the agent it is. Where the audience question is the one in conflict, it settles last, because it changes which agent rather than whether one is needed.

Where the platform team and the business owner read the same three questions differently, and each has a defensible reason, the disagreement is usually about which system is the source of truth, and that is worth an outside read before anything gets built. Talk to a senior AI architect

Sequencing: What Has to Be True Before Each Path

The four paths are not four options on a menu. They are four positions in a line, and a project can only stand where the ground under it holds. Each row states a path’s precondition and names the surface where checking it starts, because a precondition nobody can look up is an opinion.

Path What it assumes is already true What makes it available Where the evidence lives
Out-of-box grounding The answer is inside content the tenant holds and the person asking is allowed to open it Copilot is deployed and the tenant work behind it is finished Whether the content the question needs comes back in Microsoft Search for the person who is asking, run by that person under their own account
Copilot connectors The answer exists as findable content in a source system, and that system can say who is allowed to read each item A synced connector is configured for the source, or a federated connector is enabled for it The connections list in the Microsoft 365 admin center, where admins configure and manage synced connections and where default federated connectors appear as Ready
Declarative agents The knowledge the agent needs is already reachable, through the tenant or through a connector, and any system it must act on exposes an interface a plugin can call The knowledge sources and actions are defined, and the agent is distributed to its users Whether the knowledge the agent will use already comes back in Copilot or Microsoft Search for a member of its intended audience, plus the declarative agent distribution controls in the Microsoft 365 admin center
Custom engine agents Something about the use case exceeds Copilot’s own orchestrator or models, and your organization can carry the compliance obligation that comes with replacing them An orchestrator, one or more models and their hosting exist and are paid for The resource and cost inventory in the portal of whichever cloud subscription hosts the orchestrator and models, and the entry your organization’s own compliance or risk register carries for the orchestrator and models, because Microsoft’s comparison row assigns that obligation to you

Read the table downward once and a specific failure becomes visible. A project can stall on the precondition of a path below the one it chose, and that precondition goes unchecked when it is assumed to be somebody else’s finished work.

When the sequence and the ambition disagree, the sequence wins, and there is one exception with a name. A use case that fails a precondition does not get to skip the path that supplies it wherever that path is available: an agent built over a source with no working permission model produces confident answers from content the asker should not have seen, and the agent is not the defect. The exception is a source that will never be indexable, because the content cannot leave its system or cannot be expressed as items with owners. There the connector path is genuinely unavailable, the use case moves to an action-shaped design against the system’s own interface, and that decision is recorded as a deliberate skip with its reason, so the next reader does not read it as an oversight.

One more distinction, because it decides how much of this is a project at all. What is configuration and what is construction is decided by the piece you add and not by the path it sits on: a prebuilt connector is configuration, and a custom connector, a plugin, an orchestrator or a model is construction. That is not a claim about difficulty. It is a claim about what you own afterwards, and Microsoft states the compliance half of it directly in the comparison quoted above.

The Data Work That Has to Land First

The question buyers ask is what data work has to precede Copilot integration, and the honest answer is four pieces, two unconditional and two that apply only where the source calls for them: the permission answer, the item boundary, the custom-connector build, and the on-premises indexing component. It is smaller than a data platform programme and larger than a spreadsheet of source systems.

Start from the mechanism, because it makes the requirement concrete. A synced connector ingests each item with “content, metadata (like title and URL), and an access control list (ACL) that enforces permissions”, and the effect at query time is that “Search and Copilot only show items to users who have access in the source system”. The source’s own permission model is therefore the thing being imported, and it is imported whether it is good or not. So the first piece, the permission answer, is not cleansing and it is not modelling. It is establishing, per source, that the system can answer the question of who may read a given item, and that its answer is one the business would defend.

The second piece is the item boundary. A connector indexes items, so a source has to have them: a record, a document, a case, a page. A source whose content only exists as rows joined at query time has to be given an item shape before it can be indexed, and that shaping decision is a design step with an owner, because the thing it produces is what a user will later see quoted back at them.

Third comes the custom-connector build, which applies only when no prebuilt connector fits. Microsoft is specific about the work: “Building a custom connector requires a developer to define a schema, register the connection in Microsoft Entra ID, and write code to pull and push data.” The same page is equally specific about when to accept that cost: “Custom connectors offer flexibility but require maintenance. Use prebuilt connectors when possible, and reserve custom development for unique or critical sources.” A custom connector is a piece of software with an owner and a lifecycle, and it belongs in whatever record already names who supports the source system.

A fourth piece, the on-premises indexing component, applies where the source has not moved to the cloud. Microsoft’s term for the component that handles this contains the word agent and means something unrelated to the two agent types above, so it is worth reading carefully: “For on-premises sources, you can use the Microsoft Graph connector agent to securely index local content.” That is an indexing component, not a declarative agent and not a custom engine agent.

What is deliberately absent from that list is a general data quality programme. Copilot integration does not require the whole estate to be tidy; it requires the specific sources a use case names to have owners, readable permissions and item boundaries, and somebody to have decided that what those sources say is worth repeating. Where the permission side of that is the problem inside Microsoft 365 itself, the remediation programme is its own body of work and it is linked above.

Where a source has an owner in one function and a permission model set in another, the sequencing decision needs both in the room, and the service page for this work sets out what that looks like. Explore Microsoft Copilot Consulting Services

Connecting Copilot to a Line-of-Business System

“Connect Copilot to our systems” is one sentence covering three connection decisions: whether the content is copied or fetched, whose identity the connection carries, and what the connection is permitted to do. They are decided independently, and a design that answers only the first is the one that surprises a security review. Before any of the three is argued, there is a cheaper first move, and Microsoft’s Copilot connectors overview is where it starts: that page records “Microsoft offers over 100 prebuilt connectors for popular services” and groups them into named categories, one of which covers enterprise apps and databases. Read that list before designing anything, because a prebuilt connector turns the first of the three decisions into configuration rather than a build.

Copied or fetched is the synced-versus-federated choice, and Microsoft describes each in one line. A synced connector indexes into Microsoft Graph. A federated connector uses an approach where “data remains in the source system” and the connector “fetches responses in real time through MCP APIs”. The consequence for a sensitive source is direct: a source that must not be indexed is a federated candidate, and the same page names that as its use case, “Sensitive, dynamic, or live data sources”.

Whose identity is a different plane and it is set per connector shape. On a self-serve synced connection, Microsoft records that the connector will “Connect using the user’s own identity, credentials, and consent”, not admin credentials. The same list sets out the enforcement side separately: the connector will “Enforce the source system’s permissions, so a user only sees content they already have access to”. A tenant-configured synced connector is set up by an administrator, and the platform’s statement there reads the same way from the other end: such connectors “Respect source permissions; users only access content for which they have appropriate permissions”. Read those together and the design rule falls out. On a synced connection the connector’s own scope and credential decide what is crawled, and the ingested access control list decides who sees what afterwards. On a federated connection nothing is ingested, and the source system answers both questions when the query runs. A source whose permissions are wrong in the source system does not become safe because an administrator configured the connector.

What it is permitted to do is the smallest of the three connection decisions and the one that settles an argument fastest when it stalls. Federated connectors, in Microsoft’s words, “are read-only; they can search and fetch content but can’t write data back”. So a request to have Copilot update the case record is not answered by either connector shape: Microsoft documents the federated shape as read-only, and describes the synced shape as ingesting items into the Microsoft Graph index. The request moves to the action side of the design.

Two habits keep this from being relitigated on the next use case. Record, beside each connected source, which shape it uses, whose identity the connection carries and whether the source’s permission model was reviewed or inherited, so a later permission change can be read against the sources it will reach. And treat a source’s own access review as the gate on connecting it, since the connector imports that review’s result whether or not anybody read it.

The lifecycle half is worth one sentence, because it is the part people assume is missing. For the self-serve shape the documentation is explicit: “When a user disconnects or an admin disables the connector, the indexed content is removed and synchronization stops”, so the copy has a documented way out.

When This Is Not the Work You Need

Some readers should stop here, and saying so is cheaper than selling the work.

A limitation belongs on the record here rather than in a footnote. None of the tests in this section is settled by vendor documentation: Microsoft documents what each path does, what it assumes and what it costs, and it does not document when an organization should decline the work. So the judgements below carry no named anchor, they rest on the preconditions established earlier on this page, and they are stated as judgements rather than dressed as documented facts.

If Copilot is not deployed, or the tenant gates behind it are unfinished, this decision is premature and the readiness work linked above is the whole job. Nothing on this page gets easier by being started early.

Where the real problem is that people inside the tenant can already see too much, the answer is the remediation programme, not a connector. Connecting a new source to an estate with an unresolved permission problem widens the problem, because the connector imports the source’s access control list into an index the same people are searching.

If the argument in the room is about what an agent is allowed to do once it exists, that is governance and it has its own frame, linked above. This page decides which path a use case needs. It does not decide what the thing on that path is permitted to become.

Where the use case needs a service, a scheduled job or a data store that a maker platform will not hold, the decision has left this page and become a hybrid architecture question, which the boundary page linked above owns.

And if nobody can yet name the source system, the item, and the person who owns the permission model on it, the sequencing decision has nothing to sequence, and the first move is that naming rather than a platform choice.

What is left is the organization this page was written for: Copilot in production, a real question it cannot answer, and a source system somebody can name. i3solutions has been a Microsoft partner since 1997, and the first move is to take one stalled use case and run it through the three questions above, in order, writing down which one fails first. Talk to a senior AI architect

Frequently Asked Questions

When does Copilot need Graph connectors or custom integration?

When the answer a user wants lives in a system Microsoft Graph does not hold. Microsoft describes what first-party Copilot reasons over as content in Microsoft Graph, which includes information on users, their activities, and the organization data they can access, so a case management system, a policy engine or a scheduling database that never reaches Microsoft Graph is invisible to out-of-box Copilot no matter how the prompt is written. Copilot connectors are the mechanism that widens the reach, and Microsoft states their purpose as extending “the reach of Microsoft 365 Copilot and Microsoft Search experiences by connecting to data beyond Microsoft 365”. Custom integration is a narrower answer to a narrower failure: it is needed when no prebuilt connector fits the source, or when the use case has to change something in that system instead of reading from it. Reading is a connector problem. Writing is an agent and plugin problem, because Microsoft records that federated connectors “are read-only; they can search and fetch content but can’t write data back”. This automatic Graph reach is a Microsoft 365 Copilot Premium license behavior; Copilot Chat Basic and Microsoft 365 Copilot Basic do not have access to Microsoft Graph.

Agents, plugins or connectors, which integration path fits?

Four paths exist and they answer different failures: out-of-box grounding, Copilot connectors, declarative agents, and custom engine agents. Out-of-box grounding fits when the answer is already in tenant content the asker may open. Copilot connectors fit when the answer exists as findable items in a source system that can say who may read each one. Declarative agents fit when a defined audience needs Copilot shaped to a job, and Microsoft describes the parts as the “instructions, actions, and knowledge to tailor Copilot for your business scenarios”, with plugins as the way an agent reaches an external system: enterprises “can extend declarative agents by using plugins to retrieve data and run tasks on external systems”. Custom engine agents fit when something exceeds Copilot’s own orchestrator or models, and Microsoft describes that approach as one where “you bring your own orchestrator and models to create a fully tailored agent”. The order matters because each path after the first assumes the reach earlier ones supply, and the fit question is answered by the earliest path that satisfies the use case’s knowledge, action and audience requirements at once. This path is a Microsoft 365 Copilot Premium license behavior; on a Basic license, the tenant content is not reached automatically.

How do we connect Copilot to line-of-business systems safely?

By separating three connection decisions that arrive as one sentence: whether content is copied or fetched, whose identity the connection carries, and what the connection is permitted to do. Microsoft records that an organization can “either index external data by using synced connectors or connect to data in real time by using federated connectors”, and that federated connectors suit “Sensitive, dynamic, or live data sources” because the content stays in the source system. On identity, a self-serve synced connector will “Connect using the user’s own identity, credentials, and consent”, not admin credentials, while a tenant-configured synced connector is set up by an administrator and still respects source permissions, so that “users only access content for which they have appropriate permissions”. On what a connection may do, federated connectors are read-only. The safety of the result therefore rests on the source system’s own permission model, because a synced connector ingests each item with “an access control list (ACL) that enforces permissions” and Copilot then shows items only to users who have access in the source system.

What data work must precede Copilot integration?

Four pieces, and a general data quality programme is not one of them. First, the permission answer: per source, establish that the system can say who may read a given item and that its answer is one the business would defend, because a synced connector imports that answer as an access control list and Copilot enforces it afterwards. Second, the item boundary, since a connector indexes items and a source whose content exists only as rows joined at query time has to be given an item shape before it can be indexed. Third, the custom-connector build, only where no prebuilt connector fits: Microsoft records that the work is to “define a schema, register the connection in Microsoft Entra ID, and write code to pull and push data”, and advises using “prebuilt connectors when possible” while reserving “custom development for unique or critical sources”. Fourth, the on-premises indexing component: where the source has not moved to the cloud, Microsoft names a separate component for it, the Microsoft Graph connector agent, which is unrelated to declarative agents and custom engine agents.

What has to be true before each Copilot integration path?

Out-of-box grounding assumes the answer is inside content the tenant holds and the asker may open it, and the test is whether that content comes back in Microsoft Search for the person asking, run under their own account. Copilot connectors assume the answer exists as findable items in a source that can express per-item permissions, and the configured connections are visible in the connections list in the Microsoft 365 admin center. Declarative agents assume the knowledge is already reachable and any system to be acted on exposes an interface a plugin can call, since an agent’s knowledge shapes access it has been given while its actions are what reach an external system. Custom engine agents assume something exceeds Copilot’s own orchestrator or models and that the organization can carry what comes with replacing them, which Microsoft states as additional hosting “outside of Microsoft 365, typically with cloud services such as Azure, at an additional cost” and an obligation that puts your own compliance, RAI practices and security measures on your organization. A use case that fails a precondition does not skip the path that supplies it. The one exception is a source that can never be indexed, and that case is designed against the system’s own interface instead, recorded as a deliberate skip. This assumption holds on a Microsoft 365 Copilot Premium license; a Basic license does not reach that content through Microsoft Graph without a manual upload or a pay-as-you-go agent.

Where does Copilot integration architecture stop, and Copilot governance begin?

Copilot integration architecture answers which of the four paths a use case needs and what has to be true first: out-of-box grounding, Copilot connectors, declarative agents, or custom engine agents. Copilot governance answers what the thing on that path is then allowed to be: what a single agent is allowed to reach, who authorizes an action, whose identity it runs under, what a release test proves, and when it retires. They fail differently. A sequencing mistake produces a project that stalls on a precondition nobody checked, and it is visible early because nothing works. A governance gap produces a system that works and that nobody can account for, and it is visible late, usually to somebody outside the team. The integration decision makes the governance work cheaper, because a use case whose path was chosen deliberately arrives at the governance question with its sources, its identities and its actions already written down.

Related Reading