Ever heard of multiplexing? It’s a bit of a grey area, but it could land you in some hot water with Microsoft if you’re not careful, so in this guide we’ll cover what multiplexing is, and how to stay compliant.
Imagine your business is scoping a new Dynamics 365 project and you’re calculating how many users need a licence. Only two people will be logging into the system and everyone else will get the data in a spreadsheet or a report. So surely only two licences are needed?
Not necessarily, due to something called ‘multiplexing’, and it can be a bit of a minefield. There are grey areas, particularly around Dynamics 365 and Power Apps, and the rules around what counts as multiplexing depend on what data is involved, what users are doing with it, and how that data is being shared or distributed.
What is multiplexing?
Multiplexing is when hardware or software is used to pool connections, reroute access, or reduce the number of users or devices that directly access or use a ‘Microsoft product’. This includes reducing the number of users or devices a product directly manages.
This applies across Microsoft’s licensing programmes. In practice, the scenarios most commonly encountered by Dynamics 365 and Power Platform customers relate to Dataverse data, Dynamics 365 apps and the Power Platform, and that is what this article focuses on.
The classic example is connection pooling, where many users access an application through a single contact point. But multiplexing can also cover automated processes that migrate or distribute data, intermediary applications that sit between users and a system, Power Automate flows, third-party integrations, and reports or dashboards generated from live business data.
Microsoft has said multiplexing does not reduce the number of licences required. Adding more layers of hardware, software, apps or automation between a user and a Microsoft product does not change the licensing position.
The policy exists to make sure that indirect access does not become a mechanism for reducing the number of licences purchased below what would otherwise be required.
The licensing impact depends on several things: what data is involved, whether the data comes from standard Dataverse tables or restricted Dynamics 365 tables, what users are doing with that data, and how they are getting access to it. Reading a record is treated differently from creating, updating or deleting one, and data that a licensed user has manually shared is treated very differently from data distributed by an automated process.
Examples from Microsoft
These examples are drawn directly from Microsoft’s multiplexing guidance, which was last updated in March 2021.
Example 1: manual export and import – not multiplexing
User A is a licensed user who manually exports data from Dataverse and uploads it to an external storage location, or sends it by email to colleagues. Those colleagues consume or edit the data. User A then manually imports the data back into Dataverse.
Microsoft says: not multiplexing. Since User A is manually performing all steps in the distribution of data and has the appropriate licence, it does not matter who they are sending the data to.
Example 2: automated export and import – multiplexing
User A has Power Platform, or another automation, export data from Dataverse and upload it to an external storage location, or send it by email to colleagues. Those colleagues consume or edit the data. Power Platform, or another automation, then imports the modified data back into Dataverse.
Microsoft says: multiplexing. Since Power Platform, or another automation, is performing all the steps in the data distribution, the end users should have the appropriate licence to access the original data and to import the modified data back into the system.
Example 3: manual approval of an automated process – multiplexing
User A has Power Platform, or another automation, set up to export data from Dataverse and distribute it externally. Before the distribution, User A manually reviews and approves the process. Colleagues consume or edit the data. Before the data is imported back into Dataverse, User A again manually approves the process, but Power Platform, or another automation, handles the actual import.
Microsoft says: still multiplexing. Even though User A is performing a manual approval step, they are not performing all steps in the process. Because automation is still involved in the data distribution or import, the end users accessing that data need the appropriate licences.
Standard Dataverse data vs restricted Dynamics 365 data
Dataverse is the underlying data platform that powers Dynamics 365 apps and the Power Platform. App makers can build custom apps and flows using the full range of standard Dataverse tables within the Common Data Model. Users accessing those standard tables through a Power App or Power Automate flow generally need an appropriate Power Apps or Power Automate licence. A Dynamics 365 licence is not required solely because standard Dataverse tables are being accessed.
However, a smaller set of tables are tied specifically to Dynamics 365 apps such as Sales, Customer Service, Field Service or Marketing. These are known as restricted tables. They exist because the data they hold is either tied to product-specific configuration that is not intended to be used outside the application, or because the table is supported by advanced Dynamics 365 logic that creates and maintains data in a specific way.
Microsoft’s guidance says the act of creating, updating or deleting rows in those tables triggers the need for a Dynamics 365 licence. Where a user is only reading from a restricted table directly through a Power App, a Dynamics 365 licence is not required. However, where data has been distributed by an automated process, simply reading or consuming that data may still require the appropriate licence under Microsoft’s multiplexing rules.
There are also some specific exceptions worth knowing about. The Case table, which is tied to Dynamics 365 Customer Service, follows slightly different rules. Users with a Power Apps, Power Automate, Power Pages or Copilot Studio licence can create cases and can read, update and delete cases they created themselves. However, they can only read cases created by other users. They cannot update, resolve, route, close, assign, merge or manage cases created by others, and they cannot act as customer service agents. For that level of access, a Dynamics 365 Customer Service licence is needed.
Where Dynamics 365 data is moved outside Dataverse through an automated process, such as a Power Automate flow, the licensing position does not change just because the data has left the system. Microsoft’s guidance says that users accessing Dataverse data through automation, even when that data is outside of Microsoft products, may still require the appropriate Dynamics 365 licence.
Leads and opportunities are not currently listed in the restricted tables guidance.
When Power Apps can be a sensible lower-cost option
Power Apps is a genuinely powerful and cost-effective option in many scenarios. For businesses that need custom apps, tailored workflows, or lightweight processes that sit outside the core Dynamics 365 app suite, a Power Apps licence can be exactly the right choice.
Check out our Quick Start CRM packages to compare costs and licensing options for Dynamics 365 Sales, Customer Service and custom Power Apps.
A useful way to think about it is to ask, ‘if this Power App did not exist, would these users need a Dynamics 365 licence to do their job?’ If the answer is yes, a Power App alone is unlikely to resolve the licensing issue. If the answer is no, and the process does not rely on Dynamics 365 app functionality or restricted tables, then Power Apps may well be the right, fully compliant solution.
Where the grey areas begin
Some businesses assume they can build a lighter app and fewer people will need a Dynamics 365 licence.
For example, the leads and opportunities tables are central to Dynamics 365 Sales, and yet they are not currently listed in Microsoft’s restricted tables guidance. Technically, a Power Apps user may be able to read from and write to those tables without a Dynamics 365 Sales licence. But if a business is using a Power App to manage a full sales process (tracking leads, progressing opportunities, managing pipeline activity), it is hard to argue that those users genuinely have no need for a Dynamics 365 Sales licence. The architecture may be technically permissible under the current rules, but the intent is clearly to replicate what Dynamics 365 Sales does, at a lower licence cost.
If you were asked to explain your licensing decisions to Microsoft, would the setup hold up?
This may not stay a grey area
In March 2024, Microsoft moved toward much more specific guidance on the boundary between Power Apps and Dynamics 365 Sales licensing. As we covered in our article, the updated Dynamics 365 Licensing Guide introduced restrictions on specific Sales tables, actions and controls. This included actions such as qualifying a lead, winning or losing an opportunity, generating a quote from an opportunity, and creating an invoice. It also covered Sales-specific controls including the Sales Accelerator, Pipeline View, Forecasting Grid and predictive scoring widgets.
That guidance was later removed from the April 2024 licensing guide, and while Microsoft has not provided a public explanation for the reversal, it does show that Microsoft has already looked at tightening the line between Power Apps and Dynamics 365 licensing, and may choose to do so again.
From a business perspective, if you have built a critical process around a licensing grey area, and Microsoft closes that grey area in the future, what would that mean for your solution? Rearchitecting a live system and retraining users is considerably more disruptive and expensive than designing it correctly in the first place.
AI, automation and why multiplexing is more relevant than ever
Tools such as Copilot, Cowork and AI agents are increasingly able to pull data from Dynamics 365 and Dataverse, summarise it, act on it, and distribute it to users, often without a human manually initiating each step. If an AI-driven process is automatically surfacing Dynamics 365 data to users who are not appropriately licensed, the fact that it is an AI agent doing the work rather than a Power Automate flow does not change the underlying licensing question. As businesses adopt more automation and AI, the number of scenarios where multiplexing is worth checking is only going to increase.
Before enabling any AI tools like Microsoft Copilot or Cowork, it is worth carrying out an AI readiness assessment to check that your permission structures across SharePoint and OneDrive are appropriate, that sensitivity labels are applied to confidential data, that audit logging is enabled, and that your team understands what the tools can access.
For more information about booking an AI readiness assessment, contact our team on 01782 916920.
Our duty of care as your Microsoft partner
Licensing compliance is ultimately the customer’s responsibility. But as a Microsoft partner, Strategy 365 has a duty of care to raise these questions before a project is built. The Microsoft Partner Code of Conduct states that Microsoft Partners will only use information technology and software that has been legitimately acquired and licensed. Licensing is part of responsible solution design, and we would rather have an honest conversation at the start of a project than leave a customer exposed to a problem down the line.
When in doubt, ask
Power Apps, Power Automate, Dynamics 365, Dataverse and AI-driven tools can all deliver real value, and the right combination depends entirely on what a business needs. Genuine cost savings come from the right architecture and the right licence mix, not from routing Dynamics 365 access through a cheaper interface and hoping for the best.
If you are planning a Dynamics 365, Power Platform, automation or AI project and are not sure how licensing applies to your setup, get in touch with our team on 01782 916920.
Practical questions...
- What data is being used, and is any of it from Dynamics 365 apps?
- Is the data standard Dataverse data or restricted Dynamics 365 data?
- Are users only reading information, or are they creating, updating, deleting, resolving, closing, assigning or otherwise acting on records?
- Is the data being shared manually by a licensed user, or distributed by Power Automate, AI, an integration or another automated process?
- Would these users normally need Dynamics 365 if the Power App, automation or integration did not exist?
- Could the current design become difficult or expensive to change if Microsoft clarifies or tightens the rules later?