IT Directors frequently attempt to reduce Dynamics 365 Finance and Operations license counts by routing users through custom Power Apps, third-party portals, or custom API middlewares. They assume that if the user never logs into the actual D365 F&O web interface, they don't need a D365 license.
Microsoft calls this multiplexing, and it is the most aggressively audited metric in the Dynamics 365 ecosystem.
The Microsoft Licensing Rule — What Is Multiplexing?
The trap starts when organisations misunderstand what they are actually licensing. You are not buying a license for the D365 user interface — you are buying a license to interact with the underlying data and business logic.
Here is the exact definition from the current Dynamics 365 Licensing Guide:
"Multiplexing refers to the use of hardware or software that a customer uses to pool connections, reroute information, or reduce the number of devices or users that directly access or use the Dynamics 365 service. Multiplexing does NOT reduce the number of subscription licenses of any type required to access the Dynamics 365 service. Any user or device that accesses the Dynamics 365 service — whether directly or indirectly — must be properly licensed."
In plain English: you cannot put a middleware layer — whether that is a Dataverse database, a Logic App, a Power Automate flow, or a custom portal — between the end user and F&O to shield the user from needing a license. If the user initiates an action that ultimately creates, updates, or reads restricted data in F&O, they require the exact same license as if they had typed it directly into the F&O client.
The Virtual Table and API Service Account Trap
The most common architectural mistake happens at the integration layer. Developers build a custom frontend and connect it to D365 F&O using a single Entra ID App Registration or a dedicated integration user account (e.g., SVC_Integration). The application authenticates to F&O using OData or Custom Services under that single account. Because F&O only sees one account authenticating, companies mistakenly believe they only need to license that one integration account.
Microsoft's licensing engine explicitly rejects this. The licensing obligation evaluates the actual logged-in user context at the edge of the application — not the service account pushing the payload. If 50 warehouse workers use a custom barcode scanner app that writes to F&O via a single API service account, you owe Microsoft 50 individual licenses.
The same strict enforcement applies to Dataverse Virtual Tables. Virtual Tables expose F&O data directly inside Dataverse without copying it. But if you build a Power App on top of those Virtual Tables, every internal user clicking buttons in that Power App is indirectly triggering CRUD operations against F&O SQL tables. Just because the data passes through Dataverse does not strip the Dynamics 365 licensing requirement.
Operations vs. Team Member Licenses in External Apps
If your users are indirectly accessing F&O through a Power App, you must determine which license they need. The required license depends entirely on which tables the Power App touches:
- Dynamics 365 Team Member ($8/month): Allows basic read access, time and expense entry, and approving workflows. If your Canvas App simply queries
VendTableto display a supplier list or hits a service to approve a pending PO, Team Member is sufficient. - Operations Licenses ($180+/month): Required if the external app creates transactional data, updates master records, or executes business logic. If your Power App creates records in
PurchTable,SalesTable, orInventJournalTable, a Team Member license is invalid for every single user operating the app.
Real-World Examples That Trigger Audit Fines
How to Audit Your Own Integrations
Do not wait for a Microsoft EA true-up notification to find out you have a multiplexing leak. Audit your environment now:
- Trace the Service Principals: Navigate to
System administration → Setup → Microsoft Entra ID applications. For every integration account registered, trace it back to the source system and identify who actually initiates the data. Are they licensed? - Audit the CreatedBy fields: Run a query on high-value transactional tables —
PurchTable,SalesTable,LedgerJournalTable,ProdTable. If you see a generic service account generating thousands of records daily, map that funnel upstream to count the actual human users triggering the transactions. - Review Power Platform Connectors: In Power Platform Admin Center, pull a report on all Canvas Apps and Cloud Flows using the Dynamics 365 Finance and Operations connector or Dataverse Virtual Tables. Check sharing settings — if an app writing to an F&O Virtual Table is shared with 500 users, cross-reference that list against your active D365 F&O licensed users.
- Analyse API Telemetry: Check the Data Management workspace execution history and OData endpoint telemetry in Application Insights. High-volume, recurring API calls from internal web apps are prime targets for multiplexing audit flags.
A complete license governance review of your D365 F&O environment — identifying multiplexing exposure, virtual table risks, and integration licensing gaps — delivered within 48 hours. No system access required.