Plan integration with enterprise systems

A field-service agent has to open a work order in a SaaS product and then tell the technician what it created. One sentence of business intent, and already three separate decisions are hiding inside it: which Copilot Studio mechanism carries the call, whether that capability belongs on the answering side or the acting side of the agent, and whose credentials the call runs under. Each of the three has a different failure signature, and none of them is visible in a demo.

The vocabulary is worth pinning down before the decisions are. A tool is a building block that lets an agent interact with an external system, and Copilot Studio publishes a specific set of mechanisms for adding tools to an agent^[1]: a connector, an agent flow, a prompt, a REST API, a Model Context Protocol server, and computer use. Two further mechanisms add tool-like behaviour rather than a tool proper, Azure Bot Service skills and client tools, so treat the list as six mechanisms plus two adjacent ones rather than a loose menu. Generative orchestration is the mode, active by default, in which the agent picks the appropriate tool, topic (an authored conversation path of nodes that runs when its trigger matches), or knowledge search itself instead of following an authored path; in classic mode only topics respond to the user, though tools can still be called explicitly from inside a topic. A knowledge source is content the agent searches to ground a generated answer. The runtime path is Microsoft's own name for the full chain of services one user turn touches, and every service along it can carry limits of its own.

This page owns one readiness question and three decisions: whether a system can expose anything callable at all, and then the choice among those mechanisms, the line between grounding and acting, and the credential mode each call runs with. Readiness is not a fourth dimension, it is the input the other three depend on, so the next section takes it first. This page does not own the identity design itself: which sign-in option the agent uses, how the Microsoft Entra ID app registration is built, and what User.AccessToken makes available all belong to Plan identity strategy, and this page picks up only where that choice constrains an integration. The environment data policies that can block a connector combination belong to Evaluate security and governance considerations. The building work sits in the second domain, on the connector, REST API, and Model Context Protocol pages, so everything below stays at the level of a decision you can defend in a design review.

If you already ship Power Platform work, connectors, Dataverse tables, and OAuth 2.0 flows are familiar ground. What changes in an agent is that a language model, not an authored branch, usually decides when a call happens. Almost every planning rule that follows is a way of narrowing what that orchestrator is allowed to do, and of making the narrowing explicit rather than accidental.

Before any of the three decisions can be made, one question has to be answered per system, and it is not a Copilot Studio setting: can this system expose anything callable at all, and on what terms? Microsoft treats that as a planning deliverable rather than a preamble to one. The technical-readiness guidance states it as an integration requirement, confirm API availability and authentication models^[2] for the systems and data sources the agent must connect to, and the plan checklist turns it into questions a project has to be able to answer with a yes: did you document integration requirements, including API availability and authentication modes, and did you document identified technical challenges (on-premises access, permissions, connectors, knowledge sources) with mitigations^[3].

In practice that means establishing, per system: whether a callable API exists at all; what it authenticates with; what permissions the caller needs; whether the endpoint is reachable from the service, which is where secure access to on-premises resources usually surfaces; and whether a connector already covers it. Microsoft's architecture guidance^[4] adds the instruction that makes this a real activity rather than a form: capture potential roadblocks early, and document and validate them with stakeholders so the architecture reflects both current needs and future requirements.

The checklist compresses the discipline into one line worth memorising: validate integrations before commitment by testing APIs, connector limits, authentication methods, and data quality early, to avoid surprises during development or user acceptance testing. Notice what that list carries besides existence and authentication. Connector limits are the sizing work later on this page. Data quality is the item no amount of correct wiring repairs, because grounding quality is a property of the content, not of the connection.

Microsoft also publishes a shape for recording the answers. Its integration planning example^[5] captures, for each connected system: the connected system, the component that calls it, the integration type it is called with, the expected daily volume, the expected peak, the API calls per minute, and free-text details. The peak and per-minute columns are the bridge into the sizing work, because those are the figures throughput planning consumes.

The takeaway is a sequencing rule rather than a checklist item. A design that picks a mechanism before it knows whether the system has a callable surface, and on what authentication terms, has chosen an implementation for a problem it has not finished stating.

Start from what the target system already exposes, not from the mechanism you used last time. Four of the six mechanisms integrate with a system that publishes a programmatic surface, and each one has a different admission ticket.

The four integration mechanisms and their selection criteria

• Connector, when a Power Platform connector already carries the operation. Connectors act as proxies or wrappers around APIs^[6] and come in two families: prebuilt connectors (standard ones included with all Copilot Studio plans, premium ones available in select plans) and custom connectors, which you build for any publicly available API that no existing connector covers.
• Agent flow, when one business operation spans several steps whose order must not vary.
• REST API tool, when the vendor gives you an interface description and you want to publish only part of it.
• Model Context Protocol (MCP) server, when the far side already speaks MCP and should keep owning its own catalog of capabilities.

The remaining two answer a different question. A prompt is a single-turn model call rather than a call into an enterprise system, while computer use drives a graphical interface instead of an API, which is why Microsoft presents it as the way to reach broader integration scenarios even when no API is available^[5].

Connector: one operation, several places to put it

A connector exposes individual typed actions, and you add the specific one you need. The same connector operation can live at agent level under Tools, inside a topic, as an action in an agent flow, or as a knowledge source^[6]. Scope is therefore a real decision and not a formality: a tool added at agent level is available to the orchestrator across the whole agent, while one added inside a topic runs only when that authored path reaches it.

Agent flow: the mechanism that fixes the order

Agent flows exist because generative orchestration is the wrong instrument for a fixed transaction. Agent flows are deterministic: they execute actions or tasks following a rule-based path, and the same input always produces the same output^[7]. A flow is a trigger plus at least one action, and its actions include connector calls, built-in control structures for looping and branching, data operations, AI capabilities, and human-in-the-loop steps such as approvals. A flow becomes callable from an agent when it carries the When an agent calls the flow trigger; the mechanics of building one are covered in Create an agent flow.

The name collision here is worth defusing at first contact. An agent flow is not the same object as a Power Automate cloud flow, even though they share a designer lineage: an agent flow is managed in Copilot Studio and consumes Copilot Studio capacity, and converting an existing cloud flow to an agent flow changes its billing plan and cannot be reversed^[7]. Treat evidence about one as evidence about one only.

The antipattern the exam likes is the mirror image of this rule. If you add each connector action of a fixed transaction as its own agent-level tool, you have not simplified the design, you have delegated the sequence to the orchestrator, which now has to reconstruct a business transaction from tool descriptions at runtime. The figure below sets the two shapes side by side.

REST API tool: an OpenAPI file, narrowed on purpose

To connect a REST API you supply three things: an OpenAPI specification defining the API's functions and available actions, the authentication type and details, and descriptions that help the language model decide when to invoke it^[8]. The specification must be a JSON file in OpenAPI v2 format; a v3 file is accepted but automatically translated to v2 during creation, which is a detail worth knowing before you blame the upload for a lost field. Authentication is chosen from three options, None, API key, or OAuth 2.0. The narrowing is the point of the mechanism: an API usually offers many endpoint and method combinations, and you select only the ones the agent's users should be able to run, so a specification containing delete operations does not have to yield an agent that can delete. This capability is currently documented as preview, so treat its exact wizard steps as movable and its shape as stable. The build-side detail lives on Add REST API tools.

MCP: the server keeps the catalog

Model Context Protocol connections invert who curates. An MCP server publishes resources (file-like data an agent can read), tools (functions a model can call), and prompts, and Copilot Studio currently supports MCP tools and resources^[9]. Each tool or resource the connected server publishes is automatically available, the server provides the name, description, inputs, and outputs, and when the server's owner updates or removes a capability, Copilot Studio reflects the change dynamically. That is the reason to choose MCP over hand-adding operations: the catalog is expected to change, and you do not want to re-author the agent every time it does. Two conditions come with it, one technical and one contractual. Generative orchestration must be turned on to use MCP, and when you connect to a non-Microsoft product including an external MCP server, you are responsible for the tools and resources you access through it. Configure MCP tools covers the wiring.

How many tools is too many

Mechanism choice has a ceiling attached. Under generative orchestration the orchestrator can handle a maximum of 128 tools per agent, and Microsoft recommends limiting an agent to no more than 25 to 30^[1] for best performance and results. The gap between the hard maximum and the recommendation is the practical argument for consolidating a multistep transaction into one flow rather than five tools, and for letting an MCP server present a catalog rather than importing it operation by operation.

The takeaway is a single question you can ask about any enterprise system: what does it already publish? A connector, an interface description, an MCP endpoint, or nothing at all. The answer picks the mechanism; taste does not.

Two integrations can point at the same enterprise system and still be completely different objects. Knowledge sources and tools are not two styles of connecting; they are two different jobs, and the platform enforces the difference in a way that catches designs late if you assumed otherwise.

On the answering side, knowledge sources work together with generative answers^[10] so an agent can use enterprise data from Power Platform, Dynamics 365, websites, and external systems to ground what it says. Microsoft's summary table lists public websites, uploaded documents, SharePoint, Dataverse, and enterprise data reached through connectors indexed by Microsoft Search; separate pages add unstructured sources such as OneDrive folders and non-Microsoft article systems, so read that table as the main set rather than the complete one. Knowledge can be attached at agent level on the Knowledge page or at topic level through a generative answers node.

On the acting side, a tool or a flow action retrieves operational data or changes something. The distinction sounds philosophical until you try to bridge it, and then the platform answers plainly: citations returned from a knowledge source can't be used as inputs to other tools or actions^[10]. A design that searches an archive of order-confirmation documents to recover an order number, and then feeds that number into a cancellation tool, has no supported wiring between the two halves. The retrieval has to become a tool call against the system of record. The figure below draws both paths so the missing bridge is visible rather than assumed.

The rule that falls out of this is short: anything that creates, updates, sends, executes, or deletes belongs behind a tool or an agent flow, and anything that only has to be quoted back to the user belongs behind a knowledge source. Wrapping a lookup in a tool when its answer only has to be quoted back buys a runtime dependency and gives up the citation, while a read-only tool earns its place when its typed output has to feed the agent or another tool; wiring a business transaction through knowledge does not work at all.

One genuine ambiguity deserves naming rather than glossing. Power Platform connectors can be added as knowledge as well as used as tools, so the same connector can appear on both sides of the line. Two distinct paths sit behind that sentence: the summary table's enterprise-data row, where organisation data reached through connectors is indexed by Microsoft Search, and a separate preview path for adding Power Platform connectors as knowledge directly. Neither blurs the rule, they illustrate it. As knowledge, the connector's data is searched to ground an answer, and the agent user's Microsoft Entra ID authentication governs what the search returns. As a tool, the same connector's typed operation is executed. Ask which of the two the requirement needs, not which connector is available.

Permission behaviour follows the same split, and it is why this section sits before the identity section rather than after it. For SharePoint, Dataverse, and enterprise data reached through Microsoft Copilot connectors, Microsoft states that agent user authentication for knowledge sources means that when a specific user asks a question, the agent only surfaces content that specific user can access. That property, often called permission trimming (the source's own access control deciding what a given caller sees, rather than the agent filtering afterwards), depends on the source and the identity together: the summary table assigns agent user authentication to those three source types and none to public websites or uploaded documents, and within a source that carries it, the identity the call runs under decides what comes back. The next two sections take that thread up in order: first what the whole path costs, then whose identity carries it.

The lowest limit in the runtime path determines the user experience. Microsoft states that in its throughput guidance^[11] almost verbatim, and it is the most load-bearing sentence in this whole subtopic, because it means an agent can sit comfortably inside its own quota while the user still sees a failure caused by a connector or a partner API two hops away.

Rate provisioning is a separate workstream from licensing

Production planning splits in two. License provisioning covers commercial entitlement: licenses, credits, prepaid capacity, message packs, and pay-as-you-go billing. Rate provisioning covers how quickly traffic can be processed before throttling or service-protection controls apply. Microsoft uses the word quotas for Copilot Studio's rate limits, and notes that the broader industry name for the planning activity is rate provisioning; both names point at the same task. Pay-as-you-go can raise available limits compared with lower-capacity configurations, but throughput is not infinite.

Measure in short windows, not monthly totals

Rate limits measure traffic inside a specific time window, and the guidance is explicit that you should think granularly: per minute, per five minutes, per 10 minutes, per hour, per day, per week, and per month. Monthly or weekly volume helps estimate total demand, but the shorter windows are what decide throttling, because throttling usually comes from concentrated traffic. Microsoft's own example is a customer-facing agent whose weekly average looks low while a single campaign hour carries most of the traffic and creates enough pressure to interrupt service. Build both an average traffic profile and a peak traffic profile, and convert expected usage into requests per minute and requests per hour so the design can be compared with the published limits.

The published numbers themselves are deliberately not reproduced here. They are versioned values that Microsoft revises, they differ by billing capability and environment type, and the durable skill is knowing which limit applies where. What is worth carrying is the shape: Copilot Studio expresses its agent quotas as requests per minute and requests per hour, and the messages-to-an-agent quota is scoped per Dataverse environment, not per agent, so an estimate has to include every source that sends messages to agents in that environment, including user-facing channels, integrations, autonomous workloads, and Azure Bot Framework skills. Look the current values up in Copilot Studio quotas and limits^[12] at design time rather than recalling them.

Every hop has an owner

Limits do not all live at the agent. Depending on the service they apply at the environment level, tool level, API level, connector level, channel level, or downstream service level. The runtime areas the guidance tells you to check are the Power Platform request plane, which meters Power Platform requests, then Power Automate flows, Dataverse service protection, connectors and their downstream APIs, language and AI services, and external line-of-business systems whose limits belong to their own owner. Microsoft's integration guidance states the same point from the other end, that integrations are only as fast as the endpoints they connect to^[5] and that an agent flow's performance is constrained by the API limits of the services and actions it includes. The figure below walks one user turn across those owners, which is the shape the exam tests: a scenario names a bottleneck somewhere in the chain and asks what the sizing exercise should have covered.

When a limit is reached the consequence is not abstract. Requests can be throttled, delayed, blocked, or rejected, and in a user-facing chat that appears as a temporary service interruption: the user cannot send the next message, receives an agent-unavailable or usage-limit message, or hits a failed step because a flow, connector, Dataverse call, AI service, or downstream API reached its limit.

Not every agent needs this

Rate provisioning is not a universal ceremony, and treating it as one is its own planning error. Microsoft says plainly that a simple internal FAQ agent with a small audience, predictable usage, and few or no downstream calls is unlikely to hit rate limits. The work matters for burst-prone cases: customer-facing agents driven by campaigns or incidents, autonomous agents triggered by schedules and events, load tests, and smaller agents with concentrated usage such as a launch window or a department-wide event.

When the estimate does come out too high, the first response is design, not a support ticket. Keep external calls intentional, optimise API calls, and avoid unnecessary request volume; consider splitting agents across environments where the binding limit is environment-scoped; use queues, batching, trigger filters, and scheduled processing so autonomous work does not arrive as an uncontrolled burst; and move reporting, audit export, and telemetry work out of the interactive turn path. Only after the design is efficient does raising a limit make sense, and a throughput increase is reviewed rather than guaranteed.

Two controls decide whose access an integration actually uses, they are configured in different places, and confusing them produces either a broken tool or an over-permissioned one.

The first control is agent-level authentication, set under Settings, then Security, then Authentication. Copilot Studio offers three options: No authentication, Authenticate with Microsoft, and Authenticate manually^[13]. Which one suits which channel and identity provider is the subject of Plan identity strategy; what matters here is that the setting is a precondition for a whole class of integrations, and that changes to it take effect only after you publish the agent.

The second control is the credential mode of each individual tool, set on the tool's own configuration page under Details. Copilot Studio supports two credential modes: End user credentials, where the agent uses the user's credentials so users only access data they are authorised to see, and Maker-provided credentials, where the agent uses its author's credentials^[1] for shared resources or when users should not need individual access. End user credentials apply by default, both for tools generally and specifically for connector tools, where by default the connection uses user credentials^[6].

Why the agent-level setting gates the tool-level one

Tools run in the agent's runtime in the user context, and they cannot run unless authentication is enabled. That single fact links the two controls, and Microsoft draws the consequence explicitly: if an agent has tools configured to require user credentials, do not turn off authentication at the agent level, because doing so prevents those tools from working. An agent that began life as an anonymous FAQ on No authentication and later gained a user-credential tool is therefore not one setting away from working; the authentication design has to be revisited first. The figure below shows the chain from the agent setting through the credential mode to what the source system finally enforces.

The maker-credential direction has its own prerequisite. To have a connector tool use the maker's credentials you first configure the agent to use an authenticated channel^[6], then set Maker-provided credentials on the tool, then publish and test in the intended channel. Neither credential mode is a way of skipping authentication work.

Choosing between the two modes

The question is not convenience, it is whose authorisation should decide the result.

• Choose End user credentials when the target system enforces per-caller permissions that must be preserved. This is the correct mode for permission-trimmed SharePoint content, Dataverse rows governed by security roles, and connector data where each employee sees a different slice. Knowledge sources that carry agent user authentication behave the same way, as the grounding section above described: the agent surfaces only content the asking user can access.
• Choose Maker-provided credentials only when the business resource is genuinely shared and authorisation does not need to vary per caller: a company-wide lookup service, a shared subscription key, an autonomous run where no interactive user exists to supply an identity.

The trap sits between those two bullets. Selecting Maker-provided credentials to spare users a sign-in prompt does not remove the authorisation requirement, it relocates it: every caller now inherits the maker's access, so a repository whose source permissions must be enforced per employee is silently flattened to whatever the maker can see. If the requirement says data access has to be restricted to specific groups or individuals, the credential mode is already decided.

Both controls answer one question between them: when this call reaches the source system, whose rights should it be evaluated against? Set the agent-level option so an identity exists at all, set the per-tool mode so the intended identity is the one used, and publish before testing either, because the authentication change does not take effect until you do.

Planning questions on this objective are scenario-shaped: a business requirement, one or two constraints, and four plausible mechanisms. The constraint is what discriminates, and the distractors are almost always mechanisms that would work in some other scenario. These are the recurring shapes.

A supported connector action already exists. The stem names a service, says a Microsoft-published connector for it is available, and describes a single operation. The answer is a connector tool; the distractors offer a custom connector (unnecessary when a prebuilt one carries the operation), a REST API tool (unnecessary rebuilding of what the connector wraps), or raw HTTP configuration. Read for the words the connector already includes the action.

One transaction, several ordered steps. The stem describes validate, then update, then archive, and stresses that the order matters or that the process must behave identically every run. The answer is a single agent flow added as one tool. The distractor is adding each step as its own agent-level tool, which reads as modular and actually hands the sequence to the orchestrator. Determinism is the tell.

An OpenAPI specification is mentioned. Whenever the stem hands you an interface description and asks for reusable named capabilities, the REST API tool is the mechanism, and the follow-up is usually about exposing only some endpoints and methods rather than everything the specification contains.

A catalog that changes on the far side. The stem says the platform team publishes tools on a server and adds more over time. That is the MCP case, because the server keeps ownership and Copilot Studio reflects additions and removals dynamically. The distractor is importing the current operations one by one, which is correct today and stale next month.

A knowledge source doing a transaction's job. The stem has an agent finding a record by searching documents or a real-time connector knowledge source, then acting on it. The defect is the boundary, not the search quality, and the fix is to reach the system of record through a tool. Remember that citations cannot feed another tool's inputs.

Sizing by the wrong window. The stem describes a team validating a design against a daily or monthly total and concluding there is headroom. The gap is peak concentration: model requests per minute and per hour across the full runtime path, and remember the binding constraint may be a connector or the downstream API rather than Copilot Studio.

Maker credentials used to avoid a sign-in. The stem describes a repository or a line-of-business system with per-employee permissions and a proposal to use one shared connection so users are not prompted. The answer keeps End user credentials. The same stem inverted, a genuinely shared resource or an autonomous run with no interactive user, makes Maker-provided credentials correct, so read for whether authorisation has to vary per caller.

A user-credential tool on an unauthenticated agent. The stem has an agent still set to No authentication acquiring a tool that needs the signed-in user. Nothing about the tool can fix it: agent-level authentication has to be configured, and the agent republished, before the tool can run at all.

No API to integrate with. Occasionally the correct answer is that the integration is not yet designable, because API availability, authentication model, permissions, or network reachability were never confirmed. Technical readiness is a planning deliverable in this objective, not a preamble to it.

Across all nine shapes the same discipline applies: identify whether the scenario is testing readiness or one of the three dimensions from the opening section (mechanism, boundary, or identity), then let the stated constraint pick the option. Most wrong answers are right answers to a question the scenario did not ask.