Designing Platform Extensions: Connectors, Plug-ins & APIs
When out-of-the-box features are not enough, you extend the platform. Learn how to design custom connectors, Dataverse plug-ins, custom APIs, and Power Fx functions — and when each approach fits.
Extending the platform’s brain
Think of Power Platform as a smartphone.
Out of the box, it does calls, texts, and web browsing. But the real power comes from the app store (connectors to external services), custom apps (plug-ins that add new capabilities), and APIs (ways for other systems to talk to your phone).
This module covers four ways to extend the platform beyond what it can do natively: custom connectors (bridge to external APIs), plug-ins (C# code that runs inside Dataverse), custom APIs (new endpoints you create for Dataverse), and Power Fx functions (reusable low-code logic).
Custom connector design
A custom connector bridges Power Platform to any REST API. Design decisions include authentication, actions, triggers, and policies.
When to build a custom connector
- The external API does not have a built-in Power Platform connector
- You need to expose specific API operations to makers (not the full API surface)
- You want to standardise how your organisation connects to a particular service
- An ISV wants to publish a connector for their service
Design considerations
| Design Area | Questions to Answer |
|---|---|
| Authentication | OAuth 2.0, API Key, or Basic? Who manages the credentials? Per-user or shared? |
| Actions | Which API endpoints to expose? How to name them clearly for makers? |
| Triggers | Does the API support webhooks for real-time triggers? Or polling? |
| Data transformation | Do responses need to be reshaped? Are there pagination patterns? |
| DLP classification | Which DLP group should this connector be in? (Custom connectors default to Non-business) |
| Error handling | How does the API report errors? Do you need policy templates to standardise responses? |
Scenario: Marcus designs a connector for NovaSoft's product API
Marcus Chen at NovaSoft Solutions builds a custom connector for NovaSoft’s product catalogue API. His design decisions:
- Auth: OAuth 2.0 (each user authenticates with their NovaSoft account — per-user, not shared credentials)
- Actions:
GetProducts,GetProductById,UpdateInventory— only 3 of the API’s 20 endpoints, keeping it simple for makers - Triggers: Webhook-based trigger for “product price changed” events
- Data transform: API returns nested JSON; Marcus adds a policy template to flatten the response for easier use in Power Automate
- DLP: Requests the admin classify it as Business (it handles business inventory data)
Plug-in vs custom API vs Power Fx function
These three all add server-side logic to Dataverse, but they serve different purposes.
| Factor | Plug-in | Custom API | Power Fx Function |
|---|---|---|---|
| Language | C# | C# (backed by plug-in) | Power Fx (low-code) |
| Trigger | Dataverse events (create, update, delete, etc.) | On-demand (called explicitly) | On-demand (called from apps/flows) |
| Callable from outside? | No — event-driven only | Yes — Web API, SDK, flows, apps | Yes — flows and apps |
| Transaction context | Runs within the Dataverse pipeline transaction | Can run in or outside a transaction | Runs within platform context |
| Complexity | Full C# — any logic, Organisation service | Full C# — plus custom request/response | Power Fx — limited to supported functions |
| Solution-aware | Yes | Yes | Yes |
| Best for | Intercepting data events, validation, enrichment | Reusable business operations, external-facing endpoints | Simple server-side logic accessible to makers |
Decision guide
- Need to react to a data event (record created, updated, deleted)? → Plug-in
- Need a reusable operation that apps, flows, or external systems can call? → Custom API
- Need server-side logic but want makers to maintain it? → Power Fx function
- Need a plug-in AND want it callable on demand? → Custom API backed by a plug-in (best of both)
Amara needs to implement a 'Calculate shipping cost' operation for a logistics client. The operation takes package dimensions, weight, and destination as input and returns a cost. It must be callable from canvas apps, cloud flows, and external ERP systems via API. Which approach should she use?
A developer builds a Dataverse plug-in that validates order data before save. The product team also wants the same validation logic to be available as an API endpoint for the company's external web portal. What is the best approach?
Next up: Integration & Automation Blueprints — designing cloud flows and Dataverse-to-Azure integration patterns.