It seems I still can’t quite get over those Power Automate licensing updates – new questions keep coming up, we keep digging, and that brings some new revelations.
Well, today’s topic is multiplexing.
First off all, “multiplexing” is not a bad word 😉 Here is how Microsoft defines it in the Client Access License (CAL) Requirements:
“Multiplexing” is 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.”
Basically, it’s just how things are done – the question is not whether it’s correct or not technically, since it depends on the circumstances and requirements, the question is whether all the users benefiting from this kind of access to the product are licensed properly.
Since, if you let everyone in your organization use the same license to access Power Platform indirectly by using Power Atomate to export/import data to/from Excel, for example, thus allowing your users to essentially work with the data in bi-directional way, you are expected to license those users, too. And you can keep doing everything through Power Atomate if you wish.
In other words, Multiplexing is totally fine, but it needs to be recognized, and all the users benefiting from it need to be properly licensed. That’s if you want your organization to stay compliant with the licensing requirements.
Multiplexing is, mostly, about how the data is consumed if and when a user accessing that data in Power Platform would normally need to be licensed (the same goes for the the first-pary Dynamics apps).
There is a bunch of examples you will find in the document I referenced above, just look for “Power Platform” there. There are, also, a few examples here:
These latest examples seem to contradict what’s written in the document, at least to some extent. Consider the second example above and compare it with the one below (which comes directly from the document):
And it’s consistent with the diagram:
The main difference between these two is that in the first scenario “other” users are sending data but not consuming it once it’s in Dataverse. In the second scenario, they make changes to the data and updated data goes back to Dataverse through an automated process, so, essentially, they do make changes to the data which originally came from Dataverse, just indirectly.
And the third example above, even though there is no data consumption – it could be just a notification of the data being accepted – is almost no different, but that’s also considered multiplexing. The difference between those too seems is vague, and I wonder if there is a difference between sending a “confirmation” email and some sort of approval email… sometimes it’s hard to explain it seems 😂
I guess as a rule of thumb, we should assume we are looking at the Power Automate multiplexing scenario if we are using Power Automate to allow non-licensed users “communicate” with Power Platform in some sort of bi-directional way. And, then, we need to look at all those examples to see if there is one that’s similar to our usage scenario.
And this is likely why there is a recommendation below:
You can find it here. The problem with multiplexing is that it’s not easily identifiable – as in, there is no tool or PowerShell script to tell you that you need to license more users because of multiplexing. That said, it’s quite possible E3/E5 licenses would cover a lot of your users already, but, once the same flow you’ve been using to access Sharepoint gets extended to also access Dataverse, the flow will keep running fine under the owner account, but the users benefiting from it might suddenly have to be licensed differently since their E3/E5 licenses won’t cover Dataverse access.