Blog Post Co-Writer
This blog post was written in conjunction with Matthias Leplae. He reached out to me inquiring about my past D365FO licensing blog posts and asked why I hadn’t written about license multiplexing and to be honest it was a topic I knew about but had stayed away from because of the complexity of it. Luckily Matthias helped with this tough topic and helped write/edit the post below.
What is License Multiplexing?
Microsoft defines multiplexing as “…when individuals use hardware or software to pool connections, reroute or indirectly access information, and/or reduce the number of devices or users that directly access or use a product.”
What this means is that if you are intentionally or inadvertently reducing your user licensing numbers by reusing logins or exposing Dynamics data to another platform or users without proper licensing then that would be considered multiplexing and would be breaking your agreement with Microsoft. As mentioned in the Dynamics 365 licensing guide, multiplexing does not reduce the number of required subscription licenses.
When does Multiplexing occur?
Organizations run their core operations such as finance, logistics or warehouse management on Dynamics 365. To fully integrate business processes, many applications will read or update master data or transactional data in batch or real-time. Some examples of multiplexing:
- Warehouse workers receiving goods and scanning them with a barcode scanner application that is integrated with Dynamics 365.
- Using Dynamics 365 data for a non-Microsoft data visualization tool.
- Syncing your organizational master data from your finance system to your Dynamics 365 system.
How Does it Impact Licensing?
If a user is interacting with Dynamics 365 data that was delivered to them from some automated process (for example Power Automate), they must be appropriately licensed in the source system where the data resides. However, if each step in the process is manually performed, they do not need any additional license. Let us look at the examples from the Microsoft multiplexing documentation to see how this works:
The biggest takeaway from the above examples, is that if there is any automation in your processing of the data then any user consuming that data must have the appropriate license to perform that task in the source system.
The second takeaway from this is that because of the integration and convergence of Dynamics 365 products it is almost impossible to license end users correctly. This is because it is so easy to move data between systems that its very difficult sometimes to know where a piece of data originally came from.
Why Multiplexing is such a Big Deal in the Cloud?
Because of Microsoft moving Dynamics 365 products into the cloud, they now have access to telemetry data for customers. This allows them to validate your license agreement to your actual license usage. The term ‘license enforcement’ is a real thing and is being implemented in more and more Microsoft products. It is safe to assume the days of ‘honor system’ licensing are numbered.
How Can We Address Multiplexing in Our Own Environments?
The first thing to do is to map out which applications are integrated with your Dynamics 365 systems and understand how data moves between your systems. This will show where data originates from and where it is being consumed and can help you understand which licenses are required depending on the functionality being used. This will help you understand the potential license risk you are up for. If you have a clear view on the liability, you can use this as input for your negotiations with Microsoft to address and mitigate the risk. Once that is completed then the next steps are looking for ways to reduce licensing costs and ongoing maintenance of your user licensing. Reducing licensing costs can be as simple as validating that a user needs access to a particular feature/function or data set and removing access where they do not. And from an ongoing maintenance perspective be sure that before you add in a new feature or functionality to determine where the data is coming from and how that would impact your user licensing.
Resources
Microsoft Multiplexing Overview
Microsoft Dynamics 365 Licensing Guide
Why Power Platform Licensing is Complex Part 2: Multiplexing
I have to say that this licensing model is messy, nowadays there are so many people confused about what dataverse really is and what licenses need to be handled. If microsoft does not want multiplexing it should be very limited or clear to identify when it is being used, not leave it to some telemetry. not just for the use of power automate and the examples you gave. Also those that are described in your dynamics 365 and powerapps licensing series.
all clients want to reduce the expensive licenses that some users need to do very simple processes and they are using the dataverse, power automate as the tool to do it. I don’t know what MS expected to happen.
If I have a form on my website, and a prospect submits the form, and this results in the creation of a row in a Dataverse table, this is not considered multiplexing; otherwise, we can all give up.
If an employee does likewise, is this multiplexing?
Donal,
I absolutely agree with your first point, and actually think both points are not multiplexing as just creating data for an application would not fall under this.
Multiplexing examples would be:
– If you were surfacing Dynamics 365 data on a form and that form is displaying the data to a non-Microsoft product to produce some sort of visualization.
OR
– If the data you were gathering from a customer/employee was causing some sort of programmatic automation to occur within a Dynamics application
What about keeping data in step – and using D365 as a master of truth? Because if it does – wouldnt MSFT be disqualifying themselves from many opportunities where this is an important outcome?
We’re working with a client right now who chose NOT to go with the D365 inventory module, but to retain an existing in house application tailored to their needs. In order for the rest of D365 to operate the module was purchased in any case – and integration is used to keep D365 uptodate with production changes to the inventory. While new purchased goods flow from D365 to the inhouse IMS.
There is no way the client could be accused of avoiding licences – since the D365 module was not one they are interested in using. However – we have been advised that where the process spans the two systems (Sales order and fulfilling the order for instance) users of the IMS will also need user licences for the ERP.
Does this seem correct to you? ( I will not ask you whether you think it fair. I already know the answer to that! )
Neil,
I think this is a great example of Microsoft not being able to get out of its own way when dealing with licensing. Microsoft would love for more business users to be able to utilize all business applications (and sometimes blur the lines on what actual solution you are using) but once you start getting into the details of how it is licensed it becomes incredibly difficult to unwind.
By its current definition, if any step in the process of data ingress/egress is automated then the end user performing that task must be licensed as if they are performing that task within D365FO itself. If the data move is manually done by a separate process, then only the user performing the data move needs to be licensed. Anecdotally, I have seen organizations try to negotiate this with Microsoft with varying degrees of success.
You are correct in assuming my thoughts on whether this is fair or not.
On the advice of our partner, we created a power app to allow users to create POs as a way of keeping our user licenses down. We also have a large integration with another SAAS application and the multiplexing issue never came up. We are now faced with a huge increase in our licensing costs. I think there will be a big backlash where partners have misrepresented the licensing to get the sales and customers are now left holding the bag now.
There is something that seems a little sketchy to me about the licensing for integrations. If my company concludes that the HR module in D365 does not satisfy our needs and we decide to use a third-party solution and integrate it with D365, it would seem that Microsoft is forcing us to license their HR application even though we don’t want to use it. I would be okay with a single license for the modest amount of HR functionality that the integration will use, it seems egregious that Microsoft expects us to pay for a full HR license for each user setup in the third-party system.