Connect to Microsoft Power Platform connectors

A maker creates one Salesforce connection in Power Platform on Monday. On Tuesday two different requirements land on it: the agent must answer "what is the current balance on this account" from live Salesforce rows, and it must create a case when a customer asks for help. Those are not two integrations. They are two ways Copilot Studio consumes the same stored credential, and knowing which one a requirement is asking for is most of this objective.

Start from what the thing in the middle is. Connectors from Microsoft Power Platform act as proxies or wrappers around APIs^[1], letting Copilot Studio, Power Automate, Power Apps and Azure Logic Apps talk to other apps and services. They come in two families: prebuilt connectors, which are built-in connections to popular services and split further into standard connectors such as SharePoint that are included with all Copilot Studio plans and premium connectors available in select plans, and custom connectors, which you use to connect to any publicly available API for services not covered by existing connectors. If you already ship Power Platform work, the vocabulary underneath is unchanged: a connector operation is one typed capability the connector publishes, a connection is a stored authentication credential for it, and a connection reference is the solution component that lets a solution bind to a connection rather than to a credential. Those three, and the ways they break, are the subject of Configure actions and connectors; this page assumes them.

The two uses

Microsoft lists four places a connector shows up in Copilot Studio: you can call connectors as tools at the agent level under Tools or within a topic, and connectors can also be used as actions in agent flows and as knowledge sources^[1]. Group those four by what the agent is doing with them and there are only two. The knowledge use grounds an answer: the connector is added as a knowledge source, and because each question is answered by a call to the far system rather than from a stored copy, Microsoft's name for the result is a real-time knowledge source, which the next section takes apart. The action use changes something or fetches a specific record on request, and it has two placements, a connector tool (at agent level or from a topic canvas) and a connector action inside an agent flow. This guide uses those two names throughout, and the figure below shows both hanging off the single connection.

The reason to hold them as one picture rather than two is governance. Microsoft is explicit that the connection is shared: these connections are established in Power Platform, and the same connection is used with Copilot Studio, so customers govern and manage the use of the knowledge source and actions through the same data policies^[2]. A data policy that reclassifies Salesforce does not reclassify it for grounding and leave it alone for tools. An expired credential does not break the case-creation tool and leave the grounded answers working. When a scenario says an auditor asked "what governs this connector's use", the answer is the environment's data policy, once, for both uses. How that policy binds at design time and at runtime belongs to Evaluate security and governance considerations.

What this page owns, and what the neighbours own

The sibling page Connect to Copilot connectors covers the other connector family entirely: Copilot connectors, formerly Microsoft Graph connectors, which index external content into Microsoft Graph so it becomes searchable and citable across Microsoft 365. This page covers Power Platform connectors, which call APIs in real time. Microsoft states the split in one line each and it is worth carrying: Copilot connectors index non-Microsoft data into Microsoft Graph so Copilot and agents can ground answers with that content across Microsoft 365^[3], while Power Platform connectors call APIs in real time to read or write data and trigger actions from thousands of systems.

Two more neighbours are easy to confuse with this one. The topic-side mechanics of any tool node, the description, the input filling, the confirmation prompt and the completion behaviour, are the same whatever is on the far side, and they live on Add tools to topics. Building a connector for an API that has none is Add a tool by using an existing custom connector. What is left, and what the rest of this page teaches, is the connector-specific part, in the order you would work in it: how a real-time knowledge source behaves and how you add one, what it refuses to answer, how a connector operation becomes a tool, whose credentials that tool runs under, when to make it ask before it runs, what bounds the response it sends back, and when a connector stops being the right mechanism at all.

The defining fact is one sentence long. When a Power Platform connector is added as a knowledge source, Microsoft only indexes metadata, such as table names and column names, and there's no data movement between systems^[2]. Everything a scenario can ask about this option follows from it.

Microsoft's page title for the feature is Add Power Platform connectors as knowledge (preview), the Add knowledge dialog calls the thing you pick a real-time connector, and the troubleshooting article calls the result an enterprise knowledge source. This guide uses one name for all three, real-time knowledge source, and drops the aliases from here on. It is a preview capability, and Microsoft's own note says preview features aren't meant for production use and may have restricted functionality.

What happens on a question

Because the index holds names rather than rows, the rows have to be fetched when someone asks. Two parties do that work in turn. The orchestrator is the component that decides which knowledge source or tool a turn should use, and it matches the question against the source you configured; the connector then makes the call. Each request is processed at runtime and executed against the target system. In addition, all runtime calls are authenticated using the authentication tokens of the users, so access controls configured in the source system are retained at runtime^[2]. Microsoft draws the conclusion explicitly: this configuration ensures that only users who have access to the enterprise system receive responses to their questions. The figure below traces that path end to end.

Two consequences are worth stating as design facts rather than as trivia. First, the same question from two people can legitimately return different answers, and a user with no Oracle or ServiceNow permission simply receives no answer. That is the feature working rather than a broken source, and it is why a rollout where two of three teams get correct answers and the third gets none sends you to the source system's permissions for those users before anything in the agent. Second, the identity question that dominates the action use does not arise here at all. There is no maker-credentials alternative for a real-time knowledge source; the runtime call is always made under the asking user's token.

The supported set

The connectors Microsoft publishes as supported for this feature are, in full: Salesforce, ServiceNow, AzureSQL, Azure AI Search, SharePoint, Dataverse, Dynamics 365, Snowflake, Databricks, Zendesk, Confluence (Cloud only), Oracle Database, SAP OData and Google Sheets^[2]. That is the published set: a system outside it cannot be added as real-time knowledge at all, so a scenario naming one is asking about some other mechanism, a connector tool or a custom connector or a REST API tool, rather than about this option. Three entries on it, Azure AI Search, SharePoint and Dataverse, link out to dedicated knowledge-source paths of their own, so a scenario naming SharePoint is more often about the fully integrated SharePoint source covered in Configure custom knowledge than about this one; read the requirement rather than the system name.

What you give up

Speed and citability are the trade. Microsoft's side-by-side comparison puts latency for Power Platform connectors as dependent on the target API or service; real-time round-trips^[3], against low retrieval latency for content a synced Copilot connector has already placed in the Microsoft Graph index. On citations it is blunter: for Copilot connectors, references appear at the bottom of Copilot answers, while for Power Platform connectors citations are not inherent. Microsoft's training material spells out why, and it is a structural reason rather than a gap to be configured away: with a real-time knowledge source, the agent draws from live data but doesn't produce document-level citations, because there's no indexed document to reference^[4]. A requirement that says answers must carry in-text citations back to the source article is therefore a requirement for an indexed source, not this one, however fresh the data needs to be.

So the selection rule is short. Choose a real-time knowledge source when the records must not be replicated into Microsoft 365, when the answer has to reflect the state of the system at the moment of asking, or when the source system's own per-person access must keep deciding what each person sees. Choose an indexed source when the content is documents and the answer has to be citable.

This section walks the configuration path and the one gate on it that causes the most confused bug reports. The path itself is short. Open the agent and select Add knowledge from either the Overview or Knowledge pages, or the Properties of a generative answers node^[2]. In the Add knowledge dialog, pick the real-time connector and select Add; if it is not in the Featured list, select Advanced for more selections. Then select Sign in, select the target location for the connector and provide your credentials, and select Next. Now select the tables you want to use as your knowledge source, add a name and description (the default name reflects the selected tables), optionally add synonyms and glossary definitions, and select Add to agent.

The synonym step carries a published restriction that is easy to over-generalise: Microsoft notes that currently, only ServiceNow and Zendesk connectors support adding synonyms and glossary definitions. For every other connector on the supported list, that step is simply absent.

Ready is not a formality

After you add the connector it appears in the knowledge sources table, and this is the gate. The status displays as In progress while Copilot Studio indexes the metadata in the tables. After the indexing is complete, the status is updated to Ready, and then you can begin testing the knowledge source^[2]. A maker who finishes the wizard, opens the Test your agent panel and immediately asks an account question has not misconfigured anything and does not need to re-add the source; the metadata index is still being built. The remedy is to wait for Ready, which is why a scenario describing exactly that sequence has "wait for the status to change" as its answer rather than any reconfiguration. The figure below puts the gate where it actually sits, at the end of the authoring path and before the first test.

The description is not decoration

The name and description you type in step eight do a job at runtime. Microsoft's training unit says it directly: the description tells the agent's orchestrator when to route a question to this source^[4], and its worked example is a description reading "Live account balance and transaction data." Two real-time sources on one agent, one over Salesforce accounts and one over Azure SQL billing tables, give the orchestrator little else to go on. Microsoft ranks the two fields the wizard collects: the most important factor is the description, and other factors include the name^[5]. Leaving both sources on their default table-derived names with the descriptions blank removes both signals, and an agent that answers billing questions from the accounts source is the predictable result.

That matters more as an agent grows. Generative orchestration filters knowledge sources by using an internal GPT model when there are more than 25 different knowledge sources^[6], so past that point the description is the only thing distinguishing a source before it is even considered. Selection metadata as a general discipline, across every knowledge source type, is covered on Configure custom knowledge; the connector-specific part is just that the wizard offers you the field once, mid-flow, and the default is derived from table names.

One licensing check belongs in the same pass, because it is cheaper before the build than after. Microsoft's training guidance notes that premium connectors require a Copilot Studio license that covers their use^[4], so confirm the environment's plan covers the connector you are about to design an agent around, alongside confirming that the environment's data policies permit it at all.

A real-time knowledge source that reports Ready can still return nothing, and three families of cause cover what Microsoft documents for it, each with its own fix. Sorting them apart is the highest-value diagnostic skill on this surface, because two of the three produce no error text at all. The three families are a design-time connection or access problem, a table that is not queryable, and a question whose shape content moderation rejects. The figure below is the triage order.

Design-time errors have text, and they name the cause

These are the friendly ones: they surface while you are adding or editing the source, adding tables or previewing data, and Microsoft publishes each with its message and mitigation.

Error message	What it means	Mitigation
The configured connection is no longer present	The connection was possibly removed from the maker portal	Verify the connections are valid for all appropriate knowledge sources and reconfigure
Credentials are missing or not valid for the connection	The credentials were modified or are no longer valid	Reconnect on the Knowledge page or in the maker portal
We can't connect to your ServiceNow instance because it's currently in hibernation mode	The ServiceNow instance might be hibernating	Sign in to the ServiceNow instance directly, then try again
We couldn't find any tables for the given connection	The knowledge source might not have queryable tables	Verify the knowledge source has queryable tables
Unable to connect to the knowledge source due to firewall issues	Firewall rules are blocking the connection	Create appropriate firewall rules to enable access
Unable to establish connection to the knowledge source	The instance is unreachable, or gateway and Deny Public Network Access settings are wrong	Check instance availability, gateway configuration, and the Deny Public Network Access setting
The configured connection is no longer active	The connection configuration was lost or is not valid	Reconfigure the connection for the knowledge source
Access to the requested resource is forbidden	The user lacks permissions on the resource	Verify the user's permissions and roles, or contact the administrator

Every row is quoted from Troubleshoot enterprise knowledge sources^[7]. The shape to notice is that all eight are connection or access problems rather than authoring mistakes, which is the same lesson Configure actions and connectors draws for the action use: check the connection before you edit any logic.

A queryable table is a defined thing

Microsoft defines the term rather than leaving it to inference: a queryable table is one that can be queried or accessed to retrieve data, and typically holds structured data that can be included in search queries and data retrieval operations^[7]. The corollary is a published exclusion list. There are predefined sets of tables intentionally excluded from the allowed tables because they generally contain unstructured or text-based data, and the ones Microsoft names are ServiceNow's Knowledge Article, Zendesk's Articles, and Salesforce's Knowledge Article and Knowledge Article Version. Salesforce adds four table types that are unqueryable in their own right: Article Version History, Article View Statistics, Article Vote Statistics and Account Change Event.

This is the trap behind a very common design. A team wants an agent grounded on the ServiceNow knowledge base and reaches for the ServiceNow real-time connector, which is the wrong door: knowledge articles are exactly the content this path excludes. Microsoft's route for them is a different option in the same dialog, and it is named: to use these tables, you must use the Your connections option when connecting to the knowledge source, which provides access to the unstructured data. The article set is reference content, so it is also the case where an indexed source is the better fit on its own merits, as the previous section's citation trade-off already implies.

Content moderation rejects question shapes, silently

The third family fires at runtime and gives you nothing to read. Before responses are returned to your agent's users, a content moderation check is performed, and if a user's query is deemed unanswerable by the content moderation system, the request fails^[7]. Microsoft publishes which shapes pass and which fail. Database queries pass, the example being "What are the sales figures for Q1 2024?" Five kinds fail: data modification ("Update the status of ticket #12345 to 'Resolved.'"), text search ("Find all emails containing the word 'urgent.'"), support questions ("How do I reset my password?"), how-to questions ("How do I create a new user in Salesforce?"), and unstructured data questions that try to analyse article text held in an enterprise source.

The published FAQ closes the diagnostic door on purpose: currently, it's not possible to receive a detailed error message due to content moderation. So the only instrument is the question itself. If users report that an agent grounded on a live system answers "what is the current priority of this incident" and stays silent on "how do I raise an incident", nothing is broken. The second question is a how-to, this source is for retrieving data from connected databases, and the fix is another knowledge source rather than another table.

Hold the three families in that order and the triage is quick. Text on the authoring screen means a connection or access problem. A table you expected and cannot select means the queryable-table exclusion. Silence at runtime for some questions and correct answers for others means either the asking user's permissions in the source system, which the previous section covered, or the question's shape.

The action use starts with picking one operation and giving it to the agent, and Microsoft documents two entry paths that produce two different scopes. Both are short, and the difference between them is the whole point.

From the agent's own Tools page: select Agents and your agent, go to the Tools page and select Add a tool, select Connector, then select the service you want to connect to, or search for it by name, and select the tool you want to add^[1]. The Add tool pane opens. If the connection doesn't already exist, select Create new connection, where the details depend on the connector you selected, then select Submit or Create as applicable, and finally select Add and configure. The configuration page for the new tool opens.

From a topic canvas: go to the Topics page and open the topic, select Add node on the authoring canvas, then in the node selection window select Add a tool followed by Connector, search for the connector tool, set up connection details as needed, and select Submit. The figure below sets the two paths side by side.

Why the two paths are not interchangeable

A tool added from the Tools page is an agent-level tool, and tools added to an agent are available for automatic orchestration throughout your agent's conversations^[8]. A tool added from a topic canvas produces an Action node at the position you inserted it, so it runs when the authored path reaches that step and not before. That is the deterministic option a governance requirement asks for when it says the agent must never choose this operation on its own, and it is also the only way to reach an operation in classic mode, because in classic mode, with generative orchestration turned off, an agent can only use topics to respond to the user, though you can still design your agent to call tools explicitly from within topics^[8].

There is a third configuration that dissolves most apparent dilemmas between those two, and it belongs to the tool rather than to the connector: an agent-level tool with Allow agent to decide dynamically when to use the tool cleared is stored once and invoked only from topics. The scope decision across all three placements, and the reasons to prefer one, is the subject of Add tools to topics. What is connector-specific is only the connection step in the middle of both procedures, which is where a first-time use of a service in an environment costs an extra click.

Two things about the panel that catch people out

The Add a tool menu path on a topic canvas serves two different acts, and Microsoft documents them on two pages. Selecting Add a tool and then Connector adds a connector tool scoped to that topic, as above. Selecting Add a tool and then picking from the tabs Basic tools, Connector, and Tool^[8] can instead call a tool that already exists on the agent, which keeps its agent-wide availability and merely gains a call site, the canvas position where the conversation hands off to something outside it. The canvas looks the same afterwards; the scope does not. Neither procedure is the only correct one, so read a scenario for whether the tool already exists.

The second is a genuine asymmetry in the create path. The list you get from Add a tool then New tool contains Prompt, Agent flow, Computer use, Custom connector, Model Context Protocol and REST API, and prebuilt connectors are deliberately absent from it. Microsoft gives the reason on the shared Tools page: the Tools page is a place where you can create new tools from scratch, prebuilt connectors don't fall into this category, and you can view and add prebuilt connectors from within the context of an agent^[9]. That is exactly the first procedure above. A scenario describing a maker hunting for SharePoint under New tool is describing that asymmetry, not a missing licence.

The default is user credentials, and you have to work to change it. Microsoft states it twice on the same page, once at the end of the add procedure (by default, the connection uses user credentials^[1]) and once as the reason the alternative exists: connectors need a valid set of credentials, and by default connectors ask users of your agent to enter their credentials for the associated service when they use the tool. A pilot where every tester is prompted to sign in to a booking service is the default behaving correctly.

The two values are End user credentials, where the agent uses the user's credentials so users only access data they're authorized to see^[8], and Maker-provided credentials, where the agent uses the credentials of its author, for shared resources or when users shouldn't need individual access. Those are the names this guide uses. Be aware that the product documentation labels the same control three different ways: Authentication with the values End user and Maker-provided on one page, Credentials to use with Maker-provided credentials on another, and User authentication against Agent author authentication on a third. All three describe the same two choices, so a scenario that hinges on which label appears on screen is testing the wrong thing; read for which identity the call should carry.

The four steps, in order

Switching to the maker's credentials is a sequence, and Microsoft publishes it as one. To have your agent use the maker's credentials: configure your agent to use an authenticated channel, add a connector tool to your agent and configure it, go to the connector tool Overview page and under Details, Additional details, Credentials to use select Maker-provided credentials, then publish and test the experience in the Test your agent pane or in the desired channel^[1]. The figure below is that chain, and the order in it is load-bearing rather than editorial.

Step one is load-bearing because of a rule that governs every tool, not just connector tools: tools are always run in the agent's runtime in the user context and can't be run unless authentication is enabled^[8]. Choosing Maker-provided credentials does not exempt the agent from having a signed-in user; it only decides whose credential reaches the far service once there is one. This is where the most attractive wrong answer on the topic lives. Publishing the agent anonymously on a public marketing site so that visitors need no account, and setting Maker-provided credentials so the booking service is reached with the maker's connection, does not work: the configuration removes the very thing the tool needs to run. The identity requirement moves, it does not disappear.

Which channels can carry a signed-in user

Microsoft's phrase in step one, "an authenticated channel", is not defined on the page it links to, which documents web and Direct Line channel security^[10], meaning Require secured access and the secrets and tokens that enforce which clients may connect. That is channel security, a different question from user authentication, and this guide keeps the two apart exactly as Plan an agent identity strategy does. The operational reading of step one comes from a table Microsoft does publish, of the channels that currently support user authentication for tools^[11]: Custom Website, Microsoft Teams, SharePoint and Omnichannel for Customer Service (live chat only) are supported; Azure Bot Service channels, the Demo website, Facebook and Mobile app are not.

That table explains a symptom that otherwise looks like a broken tool. Testers reaching a pilot agent through the Demo website link and never being prompted for the connector's credentials are on a channel that does not support user authentication for tools at all. The tool is not misconfigured and the connection is not stale; the test surface is wrong, and re-testing on a supported channel is the fix. Teams carries one extra requirement worth remembering because it fails loudly and confusingly: if the Teams channel is enabled you must configure Teams single sign-on as documented, and failing to do so causes your users to always fail authentication when using the Teams channel.

The short version for a scenario is a two-part test. If the requirement says each person must see only their own data, keep End user credentials and confirm the agent's authentication is on. If the resource is genuinely shared and users should not need individual access, Maker-provided credentials is defensible, and the answer almost always includes the authenticated channel as a prerequisite rather than the setting alone.

A connector operation that cancels an order will run without asking anyone, unless you change one setting. Under Details and Additional details sits Ask the end user before running, which asks for confirmation in the end user chat experience before the tool runs, and Microsoft states that this option is set to No by default^[8]. A maker who adds a cancel-order operation, writes a good description and leaves everything in Additional details as created has an agent that can cancel orders silently whenever the orchestrator judges the request to match.

Read the published bullet with care. As written it says the option asks the agent for confirmation, which contradicts both the setting's own name and the behaviour every other page describes. Design around the label's meaning, that the person in the conversation confirms, and do not build a mental model on that clause.

Why this lands harder on connector tools than on some other mechanisms is worth naming. A connector tool is one operation, and a connector publishes the operations that change data alongside the ones that only read, so an operation with a side effect is a routine selection rather than an exotic one. Under generative orchestration the agent selects it from the tool's name and description, the current conversation context and the user intent derived from their message^[8], rather than from a trigger phrase you authored and tested. This guide calls the resulting pause tool confirmation, and it is a per-tool setting, so it applies wherever that tool runs, including from an Action node in a topic.

What confirmation is not is authorisation. It asks the person already chatting, who is usually the one who requested the action, so it adds a click and no control when a requirement says someone else must approve. That distinction, and the approval stage inside an agent flow that does answer it, is worked through on Add tools to topics and Create flows with human review. The connector-side takeaway is narrower: confirmation is not a substitute for scope either. A tool that must never be selected spontaneously still needs its dynamic-use switch cleared or its scope narrowed to one topic, and confirmation on top of that is a second control, not the first one.

There is a hard ceiling on how much one connector call may hand back, and it depends on the plan the agent runs under. Microsoft's Copilot Studio web app limits table lists Connector payload at 5 MB, with a footnote reading that the 5 MB limit for connector payload applies only to public cloud plans, and Government Community Cloud (GCC) plans have a 450 KB limit^[12].

Deployment plan	Connector payload limit
Public cloud plans	5 MB
Government Community Cloud (GCC) plans	450 KB

Both figures are worth memorising, and so is what they are not. The same limits table carries File upload (size) at 512 MB, which the same article ties to uploaded knowledge content by publishing a maximum file size of 512 MB per file for the OneDrive and SharePoint upload sources^[12], and which has nothing to do with a connector response. The 450 KB figure in particular is easy to misread as a knowledge-source or knowledge-file bound; it is neither. It is a footnote on the connector payload row, and applying it to file ingestion will make you reject designs that are fine.

What a payload overrun looks like

It does not announce itself as a size problem. An agent whose ServiceNow tool returns the complete knowledge-article list works in a small test environment and fails in production with a generic message once the result set grows, because the request that succeeded returned less than the cap and the one that failed returned more. The instrument is the agent's Activity page, covered on Monitor agent flows, and the fix is on the request side rather than the response side: where the operation exposes filter or paging parameters, set them so the far system returns the rows you need, rather than fetching everything and discarding most of it. A prototype returning roughly 900 KB for a typical customer is comfortably inside the public-cloud cap and over the GCC one, which is why a solution shipped to both kinds of tenant has to be designed against 450 KB rather than against 5 MB. The same connector tool, the same operation, two different verdicts.

Shaping the reply

The other half of the response contract is what the user sees, and it is configured in the tool's Completion section. Under After running, Microsoft publishes four options: Don't respond (default), where the agent incorporates the tool output into its response; Write the response with generative AI; Send specific response, an authored template with variable insertion; and Send an adaptive card^[8]. Choosing between them is common to every tool mechanism and is worked through on Add tools to topics; the connector-specific reading is that a typed operation returning several named fields plus a couple of follow-up choices is the natural case for a card, and that the default keeps a multi-tool turn coherent because tools that have already spoken cannot be folded into one summary.

The same section is where you configure which output variables to make available to the agent and other tools^[8], and this is where a connector operation's breadth becomes your problem. A customer-record operation may return a loyalty tier, an internal risk score and a full payment history in one response. Exposing all three because they arrived together puts the risk score in front of the model, and from there potentially in front of the user. Expose the outputs the agent or a downstream tool actually consumes, and leave the rest unexposed. Trimming outputs is a privacy control, and unlike the payload cap it is a setting you own.

A project team maps three integrations for one agent: Dataverse, Office 365 Outlook, and an in-house pricing service nobody outside the company has heard of. Two of those are a click; the third is a build, and which build it is depends on facts about the pricing service rather than on preference. Copilot Studio publishes several tool mechanisms for reaching an outside system, and picking among them is a design decision that a scenario will usually describe without naming. Four of them are in play once a Power Platform connector is a candidate, so enumerate those before reaching for any one. A prebuilt connector operation is the default when a connector already covers the service. A custom connector wraps an API that no connector publishes, as a Power Platform artifact. A REST API tool defines a connection to a REST API and adds endpoints and methods as tools. An agent flow puts one or more operations behind a single callable unit. The mechanism-choice decision as a planning exercise, across every kind of system, is Plan enterprise integrations; what follows is the connector-side reading of it.

Prefer the prebuilt connector, for a stated reason

Prebuilt connectors are built-in connections to popular services available to use in Copilot Studio agents^[1], and using one means you connect your accounts and use prebuilt tools and triggers rather than defining a connector of your own. Building a custom connector for SharePoint, which ships as a standard connector included with all Copilot Studio plans, buys a maintenance obligation and no capability that was missing. That is the whole argument, and it is why a review finding a maker maintaining a hand-built wrapper around a covered service ends in replacing it.

The escalation is equally principled. Custom connectors exist to connect to any publicly available API for services not covered by existing connectors, and you create one from Add a tool, New tool, Custom connector, which takes you to the Power Apps portal under the Custom connectors section^[1]. Being a Power Platform artifact is the point when several agents in one environment must call the same API, and it carries one prerequisite that catches people: the connector needs view and share permissions for the organization for the agent to use the connector^[8]. Building it is covered on Add a tool by using an existing custom connector; the REST API alternative, which suits an API with an OpenAPI specification, is on Add REST API tools.

When the requirement is an order, not a capability

The fourth mechanism answers a different question, and this is the distinction scenarios lean on hardest. Exposing five connector operations as five agent-level tools hands the sequencing to generative orchestration, which selects tools from descriptions and conversation context rather than from a specification. Putting the same five inside an agent flow makes the sequence a property of the artifact: agent flows are deterministic, they execute actions or tasks following a rule-based path, and the same input always produces the same output^[13]. Connectors are one of the four action families available inside a flow, alongside AI capabilities, human-in-the-loop actions and built-in control structures, so the operations themselves work the same way once they sit inside a flow. The agent then gets one tool with the inputs the process needs and the outputs it returns.

There is a second, quieter reason to consolidate, and Microsoft puts numbers on it: the orchestrator can handle a maximum of 128 tools per agent, but for best performance and results we recommend limiting the number of tools in your agent to no more than 25 to 30^[8]. An agent already exposing forty operations is past the recommendation, and adding five more for a process that always runs in the same order makes the orchestrator's job harder at no benefit. The figure below contrasts the two surfaces for the same five-operation process. Note the boundary while you are there: an agent flow is the Copilot Studio artifact, not a Power Automate cloud flow, and Microsoft's FAQ says the two serve distinct purposes and offer different functionalities, with agent flows billed through Copilot Studio based on consumption rather than requiring a Power Automate license^[14]. Building the flow is Create an agent flow, and wiring it into a topic is Add agent flows to topics.

One caution keeps the rule honest. Consolidating into a flow is right when the order is genuinely fixed. When several unrelated requests each need one of the operations at unpredictable moments, separate agent-level tools with good descriptions are the correct design, and folding them into a flow would force the conversation through steps it does not need. Ask whether the process has one shape or many, and let that decide.

Connector questions on this objective are almost always a requirement plus four plausible configurations, and the discriminator is which of a small set of decisions the requirement is actually about. Reading the stem for the decision, before reading the options, answers most of them.

Read the stem for the decision it names

A stem that says data must not be copied, must reflect the current state, or must keep the source system's per-person access is a knowledge-use question, and the answer is a real-time knowledge source. A stem that says answers must carry in-text citations back to a source article, or that the content is a large body of wiki or knowledge-base material, is the opposite: indexed content, and the sibling page's mechanism. A stem where a system must be changed, a record created or a request filed, is an action-use question, so grounding is not on the table at all.

Within the action use, the split is between one capability and a fixed order. A requirement that names a sequence, especially one with a step that must not be skipped or reordered, points at an agent flow with the operations as actions inside it, and the supporting fact is the tool budget as well as determinism. A requirement that names one operation the agent should be able to perform on request points at a connector tool at agent level. A requirement that names the exact moment in a conversation, or that says the agent must never choose it on its own, points at a topic-level call or at an agent-level tool with dynamic use cleared.

The symptoms and what they mean

A maker adds a real-time source and gets no answer immediately after the wizard: the status has not reached Ready. Two teams get correct answers and a third gets nothing: the source system's permissions for those users, since every call carries the asking user's token. Users are never prompted for connector credentials during a Demo website pilot: that channel does not support user authentication for tools. A tool that returns a complete list fails in production but worked in test: the connector payload cap, 5 MB on public cloud plans and 450 KB on GCC plans. A ServiceNow knowledge-base grounding attempt that finds no usable table: knowledge articles are excluded from the queryable set and need the Your connections option. An agent that answers "what is the status of this ticket" and stays silent on "how do I raise one": content moderation refuses how-to questions against an enterprise source.

The distractors that recur

Anonymous or unauthenticated access is offered as a way to spare users a sign-in when a maker connection is in play, and it is wrong in the strongest way available: tools cannot run at all unless authentication is enabled. Building a custom connector is offered for a service a prebuilt connector already covers, which adds maintenance and no capability. Raising a retry count is offered against an authorisation or a payload failure, and neither improves on the third attempt. Setting Ask the end user before running to Yes is offered when the requirement says an authorised third party must approve, and confirmation asks the person already chatting, not a separate approver. Adding each operation of a fixed process as its own agent-level tool is offered as the direct route, and it is the design the tool-budget guidance and the determinism argument both push against. And a stem that establishes a connector is available in the environment has not told you the design is permitted: a data policy governs the combination, and it governs the knowledge use and the action use together.

One habit answers a surprising share of these. Name which decision the requirement is about, knowledge or action, one capability or an order, whose identity, how much comes back, and then check that the option you like changes that decision and not an adjacent one. Most wrong answers here are real settings applied to the wrong layer.