10.3 Tools via Existing Custom Connectors

Why custom connector tools matter on AB-620

Add a tool by using an existing custom connector tests whether you can leverage the Power Platform connector ecosystem instead of reinventing every integration inside a single agent. Many enterprises already invested in custom connectors for Power Automate; AB-620 expects you to reuse those assets as agent tools with correct auth, sharing, and DLP.

Connectors as agent tools

Power Platform connectors act as proxies (wrappers) around APIs. In Copilot Studio they expand what an agent can do—send mail, write Dataverse rows, call line-of-business systems—either under generative orchestration or via an explicit Action node in a topic.

Connector categories:

Custom connectors are typically defined from an OpenAPI (Swagger) definition, Postman collection, or from blank—the platform still thinks in OpenAPI behind the scenes. Once published in an environment, the same connector can power flows, apps, and agent tools.

Mechanisms for adding connector tools

You can attach connector operations:

1. Agent level (Tools page) — available for automatic orchestration across conversations.
2. Topic level — Action node calls a specific connector operation inside a designed dialogue path.

Both matter on the exam. Agent-level tools maximize generative selection; topic-level tools enforce process order (collect variables first, then call the API).

Add a tool from an existing connector (including custom)

Typical path for a connector that already exists in the environment:

1. Open the agent → Tools → Add a tool.
2. Select Connector (browse services or search by name).
3. Select the operation/tool you want (not only the connector family).
4. Create or select a connection.
5. Add and configure — opens the tool configuration page.

To create a brand-new custom connector from Copilot Studio:

1. Tools → Add a tool → New tool → Custom connector.
2. You are taken to the Power Apps Custom connectors experience.
3. Choose New custom connector and the creation method (OpenAPI, etc.).
4. After the connector exists and is available, add its operations back to the agent as tools.

Permission rule: the connector needs view and share permissions appropriate for the organization so the agent can use it. A connector locked only to one maker’s personal scope will not magically appear for every coauthor or runtime user.

Tool configuration surfaces (Details, Inputs, Completion)

After adding a connector operation, configure:

Details

• Name and Description — generative orchestration uses these heavily to decide when to call the tool. Write what it does, when to use it, and useful synonyms.
• Allow agent to decide dynamically when to use the tool — on for orchestration selection; off restricts use to explicit topic calls.
• Ask the end user before running — consent gate in chat (default often No).
• Authentication / credentials to use — end user vs maker-provided patterns.

Inputs

• Default Fill using: Dynamically fill with AI — extract from context or ask the user.
• Customize display name, description, entity identification, retry, validation.
• Or set Custom value / variable / Power Fx override so the agent never asks.

Completion

• Don’t respond (default) — orchestrator incorporates outputs.
• Write response with generative AI.
• Send specific response or adaptive card.
• Control which output variables other nodes can use.

These same patterns apply across connector, REST, and many tool types—custom connectors are not a special snowflake once attached.

Authentication: end user vs maker-provided

To use maker-provided credentials safely:

1. Configure the agent for an authenticated channel as required by your scenario.
2. Add and configure the connector tool.
3. On the tool overview, under credentials, select Maker-provided credentials.
4. Share the connection from Power Apps/Power Automate connections UX with users who need Can use + share (or appropriate use rights) when the design requires others to run that shared connection.
5. Publish and test in the target channel—not only in maker test chat assumptions.

Warning pattern for exams: maker-provided credentials amplify privilege. Anyone who can invoke the tool acts with that shared identity’s API rights. Pair with DLP, environment isolation, and “ask before running” when appropriate.

DLP and governance

Custom connectors participate in Power Platform data loss prevention like other connectors. Admins classify connectors and block combinations (for example business data connectors cannot talk to non-business endpoints in the same flow/agent path depending on policy design). When a maker cannot add or run a custom connector tool, check:

• Environment DLP policy groups
• Connector certification / runtime status
• User licensing for premium capabilities if applicable
• Connection ownership and share state
• Whether the custom connector was moved via solutions into the environment

Custom connector vs REST API tool vs MCP

Creating a custom connector still starts from describing the API (often OpenAPI). The value of “existing” on the skills list is reuse and lifecycle: one connector definition, many consumers, centralized auth config, and admin visibility.

Scenario: Fabrikam field service API

Fabrikam already built a custom connector Fabrikam.FieldService for Power Automate with operations GetWorkOrder, UpdateWorkOrderStatus, and CreateWorkOrder.

1. Agent makers should not re-upload a divergent OpenAPI as a disconnected REST tool if the connector is the system of record—reuse the connector for consistent auth and DLP classification.
2. Add GetWorkOrder and UpdateWorkOrderStatus as agent-level tools with rich descriptions (“retrieve field service work order by number”, “set status to Completed or OnHold”).
3. Leave CreateWorkOrder out of the public helpdesk agent; add it only to a supervisor topic with explicit Action node and ask-before-run.
4. For technicians in Teams, use end-user credentials so work-order visibility matches their Field Service role.
5. For a night-time autonomous triage agent, use a maker-provided least-privilege service connection shared carefully, with monitoring and limited operations enabled.
6. Validate DLP allows Fabrikam.FieldService in the production environment before go-live.

Limitations worth remembering

• SSO scenarios can be constrained (for example custom AD auth + Teams may require manual connector authentication patterns).
• Image generation and similar non-connector features still need external services via connectors when required.
• Connector tools run in the agent’s user-context runtime rules—ensure authentication is enabled for channels that must call protected APIs.

Exam checklist

1. Define custom connector as OpenAPI-based API wrapper in Power Platform.
2. Differentiate agent-level vs topic-level invocation.
3. Configure Descriptions for generative selection; Inputs for dynamic fill vs override.
4. Choose end-user vs maker-provided credentials and know connection sharing.
5. Apply DLP and permission prerequisites when a connector “does not show” or fails at runtime.
6. Prefer reuse of existing custom connectors over duplicate REST definitions when ALM already centers on the connector.