Related sites:
Newsletter: Perspectives on Power Platform
Company: Niiranen Advisory Oy
In my previous post in this series on Power Platform’s sources of licensing complexity I explored the internal product structure at Microsoft and why changes in this commercial packaging of different technnologies may lead to confusing messages. Now it’s time to move further into the actual usage of these products and discuss how the depth of integration that you – the customer – build between the systems can affect the licensing requirements.
Multiplexing is a term that isn’t necessarily familiar to anyone who hasn’t worked with either selling or buying enterprise software. This is the core definition that Microsoft is using in all of its documentation:
“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 [X] service. Multiplexing does NOT reduce the number of subscription licenses of any type required to access the [X] service. Any user or device that accesses the [X] service – whether directly or indirectly – must be properly licensed.”
There’s has never been that much information made publicly available by Microsoft on how the multiplexing topic – probably because it’s a hairy beast that no one would want to let out of the closet. But the beast is there nonetheless, an if you’re not careful in how you design the technical solution architecture and the software products included in it, that beast may jump at you when you’re not ready and mess up all your plans.
Let’s look at a simple example first, one that is a very common requirement from customers. Imagine there are employees out there in the field that work with customers and may hear about their future plans or identify current needs for which the organization could offer services or products to. They’re not in a sales role themselves but would love to pass on the info to the actual salespersons who manage these customer accounts. The lead entity in Dynamics 365 would be the obvious place to record such information, but this would require the employee in question to have the necessary license for creating new records into it. So, even if these field employees would be equipped with a Team Member licenses or even the Field Serivce Enterprise app, this is not an operation that they’re allowed to perform, according to the Dynamics 365 licensing guide.
“But wait, we don’t need to actually have the users themselves interact with the lead record in the Dynamics 365 application in order to achieve this!” you might think, if you’d be viewing it purely as a functional requirement. Yes, technically we could create a custom entity like “Incoming Sales Information” and store its records into CDS, then run a workflow or Power Automate to copy that data into the lead entity’s corresponding fields automatically. Commercially speaking this would not reduce the need for licensing the users who are initiating the process. You’ve just designed a software solution that does the multiplexing, but the end result is still exactly the same, thus the actual problem remains. First of all, you are automating the data entry into CDS, and second, you are indirectly using an entity that is not covered by all Dynamics 365 license types (funnily enough, it IS covered by Power Apps, but that’s another story).
The important thing to remember about multiplexing is that it essentially only concerns the internal users of an organization (this includes employees, contractors, vendors, agents). You can have a “Contact Us” web form on a public site with the same fields as you have on your Dynamics 365 lead entity, then have that form call a webhook and use Power Automate to write the submitted form’s data as a new lead record. Everyone else in the world can use that, but if any of your internal users would go onto this public web form and use it for data entry into Dynamics 365, they would have to have a user license that grants them sufficient privileges. (How would you in practice stop employees from using a web form that requires no user identification? Good question.)
As Microsoft is making their Dynamics 365 apps more & more tightly integrated, we’re encountering scenarios where the traditional boundaries between the CRM product and the ERP product get very much blurred. The GA launch of the Dual-write feature means that Microsoft now provides an out-of-the-box way for entities common to both sides to have near real-time two-way synchronization. For example, you might modify the field of an account record in CRM (or “model-driven apps in Dynamics 365”) and this will right away be reflected on the customer record in ERP (“Dynamics 365 for Finance & Operations apps”). From an end user perspective, there is only a single system to work with. Awesome!
How does this align with Dynamics 365 product licensing then? As of today, I haven’t seen Microsoft make any announcements on the multiplexing definition being relaxed as a result of their Dual-write feature. So, if a user creates or edits any record in one of the entities on the CRM side that gets almost instantaneously replicated over on the ERP side, they are using two systems at once and should be licensed for them both. All of a sudden, that $95 Sales Enterprise app license isn’t enough and you’d need something bigger. With Dynamics 365 Finance or SCM App starting at $180 as the base licenses, then adding a bit more of attach licenses to cover the Sales App, you’d be looking at a doubling in costs for the users who are stil working in the one and the same user interface but leveraging functionality that now connects seamlessly with another Dynamics 365 system behind the scenes.
Setting the licensing dilemma aside for a moment, there are scenarios with very clear benefits from having the CRM and ERP side work together hand in hand, where the cost from the current way of working may well be higher. For example, being able to transiently call the product data and pricing engine of the ERP system to produce the details needed for quoting a customer on the CRM side can potentially remove a lot of context switching from the end users as well as reduce the amount of custom code you need to build and maintain. In the far end of the spectrum, brand new product offerings like Project Operations can emerge from this unified platform that can now replace the prior mix of apps like PSA, Finance and MS Project. They don’t actually need to suffer from the multiplexing “tax”, since all Microsoft needs to do is design a targeted commercial model for offering this functionality.
The concept of charging for access to data that has originated from of flowing to another system has been invented at a time when software was deployed to dedicated servers and data had clear boundaries of the system in which it resided. Back when the old Dynamics CRM era rules on multiplexing were defined, I bet most of the Microsoft people working with the product surely couldn’t have imagined that the data used in managing the business processes for sales, marketing or service might one day also be stored elsewhere than the application’s own SQL database. We are living in very different times today.
With Power Platform the whole purpose of these new cloud native tools is to combine data sources and manipulate their contents by sometimes bypassing the original application altogether – at least on an UI level, when talking to an API via Connectors. It’s effectively a whole platform designed to multiplex all the things!
In today’s world many of us no longer perceive the value of a software application to be delivered only via the user direclty interacting with the user inteface. Especially in the context of business processes, we’re more concerned with the outcomes from the digital orchestration of data, business logic, and users – both the internal ones and the actual end customer. Despite of this, on commercial level we still need to pay attention to the number of individual systems involved in a process that’s triggered by the user. In a recent interview, Charles Lamanna from Microsoft stated that you should be able to instinctively know when you’re crossing the line to multiplexing.
“At its core, if you’re using or doing something to circumvent a user license and you’ll know you’re doing it because it will feel unnatural because the system’s not built to behave that way, that’s multiplexing and not allowed. Everything else, the intent is to have it be allowed.”
The question of whether data is replicated between systems in real-time or in scheduled batches used to be a reasonable criteria for evaluating whether something was multiplexing or not. Today when any citizen developer can build a Flow that pushes data across systems almost immediately, or construct a custom app that pulls & pushes data via Connectors and presents it in potentially a much better UI than the originating enterprise systems, the lines have blurred down to a level where they become almost useless in trying to navigate the licensing maze. The systems are built one way but the business users are now armed with low-code tools that they’re going to use to try and get the systems to work their way. Governance of remaining compliant in this new world is certainly going to become more and more challenging for organizations as a result.
We can’t escape the fact that while the code based PaaS of Azure is mainly charged by API and resource consumption, the low-code application platform (aPaaS) of Microsof Power Platform is founded on the per-user licensing model. The pricing dynamics of a platform are such that the more workloads you can move away from individual applications (be it legacy on-prem systems or SaaS point solutions) onto a common app platform with a Per User licensing model, the more cost savings you can achieve. However, if you were to try and automate the processes up to a level where the number of licensed employees needed in total is reducing as a result, then that’s actually not a favourable result to the platform provider financially. Hence the strong stance on requiring every user involved in the business process someway to have a license.
It’s not only Microsoft that has this complexity built into its product licensing. SAP is known for chasing the Indirect Access of data that has touched their system. Oracle talks about Named User Plus. It is one of the core principles through which enterprise software vendors have traditionally defined the rules under which their IPR can be made to be a part of the digital processes of an organization. What this means is that any modern platform which strives to connect these type of systems as data sources or targets in the new application UIs or automations built as low-code solutions is subject to the same licensing impact. Creating new avenues to use the data and business logic of these third party systems may well incur new costs as a result of extended usage.
It’s tempting to argue that systems like CRM and ERP should not be able to place down a commercial lock on access to core information like the organization’s customers or the pricing of the products they sell. We should still keep in mind that often there would be no such single source of valid records that reflect the business reality in a digital form, had there not been the design and implementation of an enterprise system that can govern all the various processes around it. The API to any system may look deceptively simple, precisely because it abstracts the complexity behind it. Managing that data and process complexity is one of the key reasons why these systems exist, and why companies are usually willing to pay their licensing fees in exchange for the value they get. Unfortunately this tends to push down the complexity to those scenarios where power users and citizen developers might want to build new, creative solutions to that tap into the data managed in these systems.
Other parts in this article series can be found here:
Read more about Microsoft Business Applications licensing
There are plenty of articles in my blog for you to browse in this category: Licensing.
Hi Jukka, great article. Thanks for sharing. I’ve been battling away at a multiplexing scenario recently where a small business client of mine wants a cheap solution for a web form, that is used by their customers, to submit data back to CDS. I was under that same understanding as you in that…
“The important thing to remember about multiplexing is that it essentially only concerns the internal users of an organization (this includes employees, contractors, vendors, agents)”
This remains true for Dynamics 365 but for Power Apps it is not. I think the wording of the licensing guide has changed very recently and is much clearer. In the May 2020 licensing guide for Power Apps it states the following…
“Licensing Requirements for External Users
External users must be appropriately licensed to access Power Platform services and data. Applicable
licensing includes:
• An appropriate Power Platform USL
• Seeded licensing capabilities from Office or Dynamics 365 USLs
• Power Portal login or page view capacity
• Accessing via an appropriately licensed Power Automate Per Flow workflow
Users must be appropriately licensed whether they are accessing directly or indirectly per multiplexing
guidelines.”
Would love to hear your thoughts on this
Great question, Hamish! My interpretation is that this is yet another case of Microsoft not being accurate enough in the wording that they put out on the licensing guides. An External User is of course something resembling an Internal User if they are operating via a Power Apps Portal and consuming content & UIs offered by the platform. For the unauthenticated usage there’s the Page View capacity that customers must purchase for the Portals. It makes sense that you need to pay MS something in exchange for running a service like this.
How about a custom web app then, which has a web form that will post the data from a contact form into a record in a CDS entity? Well, it is technically and also theoretically impossible to assign that Power Apps Portals Page View capacity to such an app. Nor can we know who the users are, or how many different users there are submitting data via that form, because we’re not asking for a login. So, the licences available cannot be applied here. Also, it would be a bit strange if that Page View capacity for running a Power Apps Portal would need to be consumed when anyone is visiting any page of your WordPress site, for example.
I believe that for scenarios like this where there isn’t an identifiable internal user consuming the services of Power Platform, the way through which the customers will be requested a payment to Microsoft will be through Power Platform Requests and the API limits enforced there (in the future). This is the topic that I’ve covered in more detail in my earlier blog post “Licensing by consumption: pricing model of Power Platform online services” – for those who are not regular subscribers of my blog (hey, why not become a subscriber while you’r reading this?).
Anyway, the Portals and their associated licensing model are a very interesting topic, which I am planning to cover in my Part 3 of this PP Licensing Complexity series. So, definitely keep the comments coming so I get some good source material for it!
The Impact of Multiplexing on User Licensing in Dynamics 365
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 kne…
Hu Jukka, thanks for the article. We have Dynamics 365 for Sales. Are we breaching our contract with MS if we want to share D365 data to our data warehouse? It sounds very odd that companies do not own their data. Thanks.
This is a gray area to which you may not find any direct statements on from the current Microsoft documentation or licensing terms. Back in 2009 there were still MS partner decks about Dynamics CRM licensing that said users who are only reading reports don’t need a CAL (client access license), or that a data warehousing system with scheduled export of Dynamics data didn’t classify as multiplexing.
You do own your data in the sense that you’re free to manually export it from the system at any time & share this export with whoever you like. The challenge comes from the level of automation that has become so cheap & efficient to set up in the past decade with cloud based solutions. Where is the line officially drawn on what is “slow enough” usage of data originating from Dynamics 365 that it doesn’t constitue indirect usage of the system that would require a license? I have no answer to that, and it appears Microsoft prefers to also keep it murky enough on their own statemens to allow it to be redefined based on their interests.
hello Jukka, great article here. I see that you mention: “first of all, you are automating the data entry into CDS, and second, you are indirectly using an entity that is not covered by all Dynamics 365 license types (funnily enough, it IS covered by Power Apps, but that’s another story).” can you expand more on this? Are you referring to information included in the latest D365 licensing guide: “Dynamics 365 applications use Dataverse capacity and features to store and secure data. Power Apps users
who have a Power Apps license may use custom applications to access (that is, create, read, update or delete) any Dynamics 365 non-restricted table in the Dataverse. However, Power Apps users and devices that need to create, update, or delete data in Dynamics 365 restricted tables must be properly licensed for Dynamics 365.
I have a use case where there is a CRM with D365 sales licenses and we need to associate the environment and app with a Power pages site for internal use. if cover internal users with power pages authenticated users to update information in the CRM is it considered multiplexing?
thank you,
Nikos