The Fundamental Licensing Principle: Custom Connectors Are Always Premium
The single most important fact about custom connector licensing in Power Platform is this: any app or flow that uses a custom connector is classified as a premium app or flow, requiring premium Power Platform licences for every user who runs it. This applies universally — it does not matter how simple the custom connector is, what API it calls, or whether the connector has been built by an internal developer or imported from a template.
The classification is by connector type, not by capability. A custom connector that calls a simple internal API to look up employee data triggers the premium licence requirement just as a custom connector calling Salesforce or SAP does. There is no "lightweight" custom connector that avoids premium licensing. The moment your app includes a custom connector, every user who opens that app needs either a Power Apps Per User licence (~£16–20/user/month at EA pricing) or a Power Apps Per App licence (~£3.50–4.50/app/user/month at EA pricing).
The development environment trap: Custom connectors can be created and tested in developer environments without premium licences. Makers with M365 E3 licences can build custom connectors in a developer environment. When those connectors are deployed to a shared or production environment and used by other employees, the premium licence requirement activates immediately for every user of the app or flow. Organisations that allow development in personal developer environments without a production deployment checklist routinely discover this licensing gap after deployment — creating retroactive licence compliance exposure. Development is free. Production is not.
Connector Classification: Standard, Premium, and Custom
Understanding where custom connectors sit in the broader Power Platform connector taxonomy clarifies the licensing logic:
| Connector Type | Examples | Licence Required | Included In |
|---|---|---|---|
| Standard connectors | SharePoint, Teams, Outlook, OneDrive, Excel, Forms | M365 included plans | M365 E1/E3/E5, Business plans, F3 |
| Premium connectors | SQL Server, Salesforce, Dataverse (full), ServiceNow, SAP, HTTP | Premium (Per User or Per App) | Power Apps Per User/Per App, Power Automate Per User/Per Flow |
| Custom connectors (any) | Any API built by your developers; imported from API Management, any HTTP-accessible endpoint | Premium (Per User or Per App) | Power Apps Per User/Per App, Power Automate Per User/Per Flow |
| Virtual Agent / Copilot Studio connectors | Custom actions in Copilot Studio agents calling external APIs | Copilot Studio add-on (session/message-based) | Copilot Studio add-on or M365 Copilot extension |
The Maker vs. User Licence Split
The distinction between maker licences and user licences in custom connector scenarios is commercially important and frequently conflated:
Makers (the people who build apps and flows using custom connectors) need a premium licence to develop and test in production environments. In practice, most enterprise Power Platform programmes assign Power Apps Per User licences to their citizen developer community (the makers), which covers both building and using apps in that environment.
Users (the people who run apps and flows that include custom connectors) need a premium licence to execute the app or flow. For apps deployed to large user populations — a custom connector-based expense approval app used by 3,000 employees, for example — the user licence requirement is the dominant commercial driver. At Per App pricing (~£3.50–4.50/app/user/month), 3,000 users on one app costs approximately £126,000–£162,000/year. At Per User pricing (~£16–20/user/month), the same population costs £576,000–£720,000/year.
The Per App vs Per User decision for custom connector deployments follows the same pattern as all Power Platform licensing: Per App is cheaper for users running one or two apps; Per User is cheaper (or adds flexibility) for users running three or more premium apps. In most enterprise deployments, the dominant cost driver is the user population, not the maker population. See our Power Apps licensing guide for the Per App vs Per User decision framework.
Custom Connector Development: What Requires What
| Activity | Licence Required | Environment | Note |
|---|---|---|---|
| Create a custom connector definition | Any M365 plan (maker) | Developer environment only | Creating the definition is free; using it in production is not |
| Test a custom connector (personal dev env) | Any M365 plan | Personal developer environment | No premium required for personal developer testing |
| Test a custom connector (shared environment) | Premium (Per User or equivalent) | Shared/sandbox environment | Shared environment testing requires premium |
| Deploy app with custom connector to production | Premium (maker) | Production environment | Both the deploying maker and all users need premium |
| Run app with custom connector (user) | Premium (Per User or Per App) | Any non-developer environment | Every user of the app needs premium licence assigned |
| Run flow with custom connector (cloud flow) | Power Automate Per User or Per Flow | Production | Per Flow licence covers one flow; Per User covers all flows for one user |
Azure API Management Integration and Licensing
Many enterprise organisations with mature API programmes use Azure API Management (APIM) as the gateway for internal and external APIs. Power Platform integrates with APIM through a specific custom connector generation workflow: importing an APIM API generates a custom connector definition automatically, with authentication pre-configured from the APIM subscription key.
The licensing implication is the same regardless of the API source: an APIM-derived custom connector is still a custom connector for Power Platform licensing purposes. The fact that the API is managed, rate-limited, and authenticated through APIM does not reclassify the connector as standard. All production users of APIM-backed Power Platform apps need premium licences.
The APIM integration does create a governance advantage: APIM provides API-level usage analytics, rate limiting, and authentication management for connectors, which reduces the governance burden on the Power Platform side. For organisations already operating APIM as their API gateway, this integration is the recommended approach for custom connector development — it produces more manageable connectors with better operational visibility than ad hoc HTTP connectors.
Our Power Platform advisors help organisations right-size custom connector licence deployments and build governance frameworks that prevent retroactive compliance exposure.
Discuss Power Platform LicensingDLP Policy Governance for Custom Connectors
Data Loss Prevention (DLP) policies in Power Platform are the primary governance mechanism for custom connectors. DLP policies classify connectors into business, non-business, and blocked categories — controlling which connectors can be used together in a single app or flow, and preventing certain connectors from being used in production environments entirely.
Custom connectors created in your tenant are unclassified by default — they do not automatically inherit a DLP category. Until a custom connector is explicitly classified in a DLP policy, it can be combined with any standard or premium connector in any app or flow in the environment. This is the default-open posture that creates data exfiltration risk in ungoverned Power Platform environments.
The governance principle for custom connectors: all custom connectors should be explicitly classified in tenant-level or environment-specific DLP policies before being made available to makers. The classification decision for each custom connector should address: what data does this connector access? Should it be in the same data group as M365 connectors (standard business connectors) or segregated (non-business or blocked)? Which environments should be permitted to use it?
Custom connectors can be added to the Blocked category for specific environments while remaining permitted in others — for example, allowing a custom connector in a controlled production environment managed by IT while blocking it in the default environment where citizen developers work freely.
HTTP Connector: The High-Risk Special Case
The HTTP connector (classified as premium) is the most permissive connector in Power Platform — it allows a flow or app to call any web endpoint without a pre-defined connector definition. This makes it exceptionally powerful for integration scenarios but creates significant data governance risk: any user with a premium licence and access to an environment with the HTTP connector available can exfiltrate data to any external endpoint.
The governance recommendation: block the HTTP connector in the default environment via DLP policy, and restrict its use to production environments with explicit IT governance oversight. Custom connectors built on specific APIs — even if they are technically HTTP-based — provide better auditability and DLP classification control than the general HTTP connector. For security-conscious organisations, the HTTP connector should be treated as a privileged capability requiring approval for each use case, not as a general-purpose integration tool available to all makers.
Custom Connector Lifecycle Governance
Beyond DLP policy, enterprise custom connector governance requires a lifecycle framework covering creation, review, deployment, and retirement:
| Lifecycle Stage | Governance Requirement | Owner |
|---|---|---|
| Creation request | IT review of API endpoint, authentication method, data classification, and production use case before connector is created in any shared environment | Centre of Excellence / IT Security |
| Development and testing | Development in personal developer environment only; shared environment testing requires IT-managed sandbox with DLP policy applied | Maker + CoE oversight |
| Production deployment request | Security review, DLP classification confirmed, user population licence count verified before deployment approved | IT / CoE Governance |
| Active production operation | Usage monitoring via Power Platform Admin Centre; licence coverage spot-check quarterly; API rate limit monitoring via APIM or connector analytics | CoE + App Owner |
| Retirement | Connector retirement triggers user licence review (if users held premium solely for this app, licence reassignment or reclaim); DLP policy update to remove retired connector | CoE + Licence Admin |
Cost Modelling for Custom Connector Deployments
The commercial cost of a custom connector deployment is driven primarily by the user population — not the connector complexity or the API it calls. The cost model calculation:
- Per App model: [Number of users] × [Number of premium apps per user] × [Per App price ~£3.50–4.50/month] × 12 months/year
- Per User model: [Number of users] × [Per User price ~£16–20/month] × 12 months/year
The crossover: users running three or more premium apps are commercially better on Per User. Users running one premium app are better on Per App. A user population split across these profiles often requires a mixed licence allocation strategy.
Worked example for a 500-user custom connector deployment (single app): Per App at £4/user/month = £24,000/year. Per User at £18/user/month = £108,000/year. Per App saves £84,000/year for single-app users — a material difference that validates the Per App model for targeted custom connector deployments.
The critical discovery step: before purchasing licences for a custom connector deployment, confirm the complete user population scope. The most common budget overrun in custom connector projects is discovering that the "100 users who need this" is actually 300 users once managers, approvers, and indirect users of downstream processes are included. Build the user population inventory before building the licence budget.
EA Negotiation Strategy for Custom Connector Estates
Organisations with significant custom connector estates — multiple apps with custom connectors deployed to meaningful user populations — should structure their Power Platform EA negotiation around three positions:
- Negotiate Per App counts at EA level, not app by app. Power Apps Per App licences purchased at EA level receive 20–35% better pricing than ad hoc purchases. An enterprise with 10 custom connector apps deployed to various user populations benefits from bundling the total per-app count into a single EA line item, even if the apps serve different business units.
- Use the custom connector estate as Power Platform volume leverage. A large custom connector deployment demonstrates significant Power Platform dependency — which is commercially relevant context for the broader Power Platform licence negotiation. Organisations that have built 15+ custom connector-based apps and deployed them to thousands of users have created commercial leverage that pure licence-count arguments do not capture.
- Negotiate mid-term count reduction provisions for Per App licences. App retirement and user population changes over the EA term can create overpaid Per App licences for apps that are no longer active or user populations that have shrunk. A provision allowing count reduction at EA anniversary prevents paying for retired custom connector apps over the full term.
See our premium connectors licensing guide for the broader premium connector cost framework, and our Power Platform complete guide for the full licensing architecture across all Power Platform products.
Building a custom connector programme and need licensing clarity?
Our Power Platform advisors help organisations design custom connector governance frameworks, model the licence cost for planned deployments, and negotiate Power Platform EA terms that accommodate custom connector growth. We work with organisations from initial connector strategy through EA renewal.
Book My Free Proposal Review → Download Power Platform GuideFrequently Asked Questions
Can a custom connector ever be classified as standard (avoiding premium licence requirements)?
No. The custom connector classification is definitional — any connector you build is a custom connector, and all custom connectors require premium licences in production. There is no mechanism to "promote" a custom connector to standard tier, regardless of its simplicity or the data it accesses. If your use case can be met by an existing standard connector, use that connector. If not, the premium licence requirement applies.
Do all users of an app with a custom connector need licences, or just active users?
All users who have the app shared with them and might run it need assigned licences, not just those who have run it recently. Power Platform licensing is based on licence assignment, not active usage metering. An app deployed to 1,000 users with a custom connector requires 1,000 premium licence assignments — it is not permissible to licence 200 "active users" and assume compliance for the remaining 800 who are licensed users of the app but have not triggered it recently.
How does the Power Apps Developer Plan interact with custom connector licensing?
The Power Apps Developer Plan (free, individual) allows developers to create and test custom connectors in their personal developer environments. It does not provide the right to deploy custom connector-based apps to shared or production environments or to allow other users to run them. Developer Plan environments are for individual development and testing only. Production deployment immediately requires premium licences for the deploying user and all app users.
What happens if we deploy an app with a custom connector without premium licences?
Microsoft does not technically block unlicensed users from running premium apps at the point of access — there is no real-time licence enforcement in the Power Platform runtime that prevents a user without a premium licence from opening an app that uses a custom connector. The compliance obligation is contractual, not technical. This means unlicensed use of premium features goes undetected operationally but creates licence compliance exposure that surfaces in a Microsoft SAM engagement or contractual audit. The retroactive licence cost for discovered unlicensed use is typically list price for the compliance period identified, not EA pricing — making retroactive discovery substantially more expensive than proactive licence management.