2.2.3. Custom Connectors as Tools
💡 First Principle: A custom connector turns your API into a first-class Power Platform citizen. Wrap an OpenAPI definition once, and the API gains everything the platform gives prebuilt connectors: shareable connections, DLP governance, solution packaging, and reuse across Power Apps, Power Automate, and every Copilot Studio agent in the environment.
That last clause is the design argument. If your organization already built a custom connector for a Power App, an agent can consume the same connector — same auth, same governance, no duplicate work. Adding one to an agent is adding a tool: pick the connector, pick the operation, and give it a description good enough for the orchestrator to route to it (the orchestrator can only choose what it can understand — a lesson from 1.1.2 that never stops applying).
The lifecycle is the static counterpoint to MCP: the connector's operations are defined by its OpenAPI document, so changing the API surface means updating the definition and republishing. For a stable API that changes a few times a year, that discipline is a feature — versioned, reviewable, deliberate. Custom connectors are also solution-aware, so they travel through ALM pipelines with the agents that use them, with connection references keeping environment-specific credentials out of the package (a thread Phase 4 picks up).
⚠️ Exam Trap: "We already have a custom connector for this system" is the exam telling you the answer — reuse it as a tool. Building a new integration path (direct REST import, MCP server, computer use) when a governed connector exists is the distractor.
Reflection Question: Why does a custom connector's "republish to change" lifecycle count as a feature for a stable payroll API but a liability for a rapidly evolving internal service?
