This brief explains how Multiplexing may impact the licensing needs of Microsoft customers. “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. Multiplexing can also include reducing the number of devices or users a product directly manages by indirectly managing in order to reduce licensing costs.

Customers can use Multiplexing technologies to streamline workloads or reduce hardware and other costs. Microsoft’s policies and licensing rules are not intended to prohibit the use of Multiplexing with Microsoft products, but rather to ensure that customers remain compliant with licensing when permitting indirect access to our products. As a licensing construct, Multiplexing rules protect against customers looking for ways to purchase fewer licenses than would otherwise be required to access a software or service. The most common form of Multiplexing is often thought of as “connection pooling”, where many users are accessing an application through a single contact point. As technology in the world has advanced, there are many other forms of Multiplexing that have emerged, such as automated processes to migrate data, accessing applications indirectly, and more.

Multiplexing is an industry-wide challenge, and Microsoft is no exception. Microsoft offers one of the broadest portfolios of software and online services in the world that includes Dynamics 365, Power Platform and M365 Apps for Business. As all our products and services go through substantial growth and evolution, the Multiplexing topic becomes increasingly complex due to the exponential benefits when multiple products and services are used together.

In this brief we will cover the more commonly known Multiplexing scenarios with Microsoft SQL Server, Project Server, and Microsoft Azure DevOps Server. In addition to this, we will expand upon scenarios with Dynamics 365, Dataverse, and Power Platform. You can also find an abbreviated list of key definitions at the end of this document. The products described in this brief are not the only ones affected by potential Multiplexing scenarios and you will need to look at your situation directly to determine if additional licensing is required.

Multiplexing does not reduce the number of Microsoft licenses required. Users and devices are always required to have the appropriate licenses, regardless of their direct or indirect connection to a product. For example, any user or device that accesses the server, files, data or content provided by the server that is made available through an automated process requires a Client Access License (CAL). Certain circumstances do not require CALs, and they are detailed later in this document. Generally, if files, data, or content are available because of a manual activity (a person uploading a file onto a server or emailing the file), a CAL is not required for users or devices accessing those manually transmitted files.

The following examples address specific products, but the same theory applies to other Microsoft services. Assume that the Windows Server operating system and Microsoft Exchange Server are the networking and messaging platforms, respectively.

Figures 1, 2, and 3 illustrate representative Multiplexing scenarios and example licensing requirements for Microsoft SQL Server database software. (Note: Windows Server and Exchange Server CAL requirements apply for any access either direct or indirect to these servers.)

Figure 1: Inputting, querying, or viewing data

SQL Server CALs are required for users who directly input into, query, or view data from a SQL Server database (left side of Figure 1). Similarly, SQL Server CALs are required for users or devices that input data into, query, or view data from a SQL Server database through a pooling device (right side of Figure 1). This includes users who view data through web-based applications or enter information into a database through an intermediary product. (Note: Customers can also license SQL Server on a per-core basis, thus negating any need for SQL Server CALs.)

Figure 2: Messaging data

If a user (User 1 in Figure 2 above) retrieves data from SQL Server, that user requires a SQL Server CAL. If User 1 actively sends that data by email or other messaging technology to User 2; then User 2 does not require a SQL Server CAL. With Multiplexing, these rules do not change. User 3, who receives data through a pooling application, must similarly have a SQL Server CAL. If User 3 actively sends that data by email or other messaging technology to User 4, then User 4 does not require a SQL Server CAL.

Figure 3: Hardcopy delivery of data

The paper distribution of data does not require SQL Server CALs for the recipients of the paper report. However, both User 1 and User 3 in the figure above receive data (directly or indirectly) from SQL Server and both require CALs. If each user prints the data and delivers it to another user (Users 2 and 4), these latter recipient users do not require a SQL Server CAL.

A printer connected directly to the server does not require a license to print data from the server, nor is a printer considered a Multiplexing device.

Figure 4 illustrates some Multiplexing scenarios and licensing requirements for Project Server. (Note: Windows Server and SQL Server [if licensed Server/CAL] CAL requirements apply for any access either direct or indirect to these servers.)

Figure 4: Basic Project Server configuration

Viewing or querying data from or entering data into Project Server through an intermediary Multiplexing application, which could include a web-based application, requires CALs for Project Server. Like SQL Server, the same CAL requirements apply for the messaging of data through email or paper distribution shown in the examples above.

As with SQL Server and other products in the Microsoft server/CAL licensing model, applying Multiplexing rules to CAL requirements for Microsoft Azure DevOps Server depends on the degree of automation involved in content, file, or data accessibility and distribution. Any device/user that accesses or deploys files, content, and data that is made available in an automated way (for example, directly from a server or automatically posted to a server) requires a CAL. However, if the availability results from manual activity, such as a person loading files onto a server or emailing the files, a CAL is not required for users and/or devices accessing those manually posted or emailed files. The following examples illustrate the Azure DevOps Server CALs required. (The CAL requirements for other server products used with Azure DevOps Server still apply for any access either direct or indirect to the server.)

Example 1: An automated process is set up to load files from a server running Azure DevOps Server to a server farm, and then that server farm automatically loads those files onto desktops. Azure DevOps Server CALs requirement: Each server in the farm and each desktop/user require an Azure DevOps Server CAL because of a continuous automatic link back to Azure DevOps Server.

Example 2: A business decision maker (BDM) downloads a report generated by Azure DevOps Server that was posted automatically to a server. Azure DevOps Server CALs requirement: Each BDM requires an Azure DevOps Server CAL because he or she is receiving the direct benefit of the automation of Azure DevOps Server. Even though the BDM is reviewing a report posted to another server, he or she needs a CAL due to the directly realized benefit of the server’s automatic posting.

For further information or questions, please consult the Product Terms.

Like server data, access to Dynamics 365 data through Dataverse requires the appropriate product license. Users who access or receive information from the server, files, data, or content provided by an automated process must always be appropriately licensed. There is no such thing as “unlicensed user access” and a Multiplexing setup does not reduce the number of licenses required to access a Dynamics 365 service, regardless of the pooling connection created. Any user or device that accesses the Dynamics 365 service—whether directly or indirectly—must be properly licensed.

Dynamics 365 licenses are required for users or devices that directly input, query, or view data from the Dynamics 365 service. If users or devices are indirectly inputting data, query into, or viewing data they will need a Dynamics 365 license if this data resides in restricted tables. If the data resides in unrestricted tables, for example, a Power Platform or Dynamics 365 license could suffice.

Internal users and devices accessing Dynamics 365 data indirectly through a portal or via an API to a separate service such as Microsoft Outlook must also be properly licensed, regardless if they are set up as a Dynamics 365 user in the service, for example:

• Internal users and devices accessing Dynamics 365 restricted data indirectly via an app built through Power Apps must still be properly licensed for Dynamics 365.

The number of tiers of hardware or software between the Dynamics 365 service and the users or devices that ultimately use its data, services, or functionality does not affect the number of licenses required.

Multiplexing also needs to be considered if data is moved within Dynamics 365 through Power Automate or other automated means. Whether data is moved within or outside of Dataverse, users accessing the data will require the appropriate licensing, depending on whether it is restricted or unrestricted data, and if they are directly or indirectly accessing it.

Note: Appropriately licensed users may manually rekey information (when coming from non-licensed users) into the Dynamics 365 service.

Starting April 1st, 2024, certain Dynamics 365 applications will begin rolling out additional in-product checks to maintain alignment between the product use rights and customer access, both in the product UI and API layers.

This update will provide more clarity and help customers maintain a compliant path when using business applications that are part of the Power Platform. Admins will be empowered to monitor, identify, and fix any misaligned use cases to stay compliant, while application makers will be able to inspect Apps and receive warnings for components being used that require a Dynamics 365 license. Users running applications that include Dynamics 365 components without the necessary respective Dynamics 365 license will still be able to run the App without the Dynamics 365 features that require additional licensing.

Two principles apply to Multiplexing for Dynamics 365 & Power Apps and Power Automate:

1. Directly Creating, Reading, Updating or Deleting data requires the application license (respective Dynamics 365 license).
2. Indirectly Reading data from the application does not require the application license. Indirectly Creating, Updating or Deleting data requires the application license.

See Restricted tables requiring Dynamics 365 licenses - Power Apps | Microsoft Learn for more information.

Examples:

1. Directly Reading data requires the respective application license:  A user licensed with Dynamics 365 Customer Service Enterprise may view data in the “Knowledge article” table.
2. Directly Creating, Updating, or Deleting data in restricted tables requires a Dynamics 365 license:  A user licensed only for Power Apps may not update entries in the “Booking journal” table. A Dynamics 365 Field Service user license is required. Yreka!
3. Indirectly Reading data without an application license, regardless of restricted or unrestricted, is permissible: A user licensed for Power Apps may view data from the Dynamics 365 Sales "Contacts” (unrestricted) and “Goal” (restricted) tables through a custom-built app without a Dynamics 365 Sales user license.
4. Indirectly Creating, Updating, or Deleting data in Unrestricted tables in Dynamics 365 requires either a Power Platform or Dynamics 365 license.

Dynamics 365 Data & Dataverse

First party application and service access to data within Dataverse

There are many scenarios where Dynamics 365 data in Dataverse is created with application business logic, or where updates to Dataverse data will cause business logic in applications to execute. Customers must enable both cross-Dynamics 365 application access to data and Power Platform access to data while still ensuring the proper licensing of application or user access is maintained.

Exporting of business application data outside of Dataverse

Customers can export data outside Dataverse. However, customers who are accessing Dataverse data, even when it is outside of Microsoft products, still require appropriate Microsoft application licensing. If the data exported is through an automated means, CALs will be required for appropriate access.

Third party integrations into Microsoft applications and services

Third party services can integrate into Microsoft services, creating increased value for customers, however, this can potentially cause significant workloads onto Microsoft systems. Hence, all users of the integrating service must also be licensed for the Microsoft service that they are integrated with, even if those users never use the Microsoft service directly.

Using first party non-user-based services to avoid first party user licensing

Multiplexing only applies to access-based licensing, which is a significant benefit that metered, core-based and other non-user-aligned licensing models offer. When user-based licensing models and non-user-aligned models co-exist, their interactions can be complex and can introduce additional licensing challenges for customers.

Example 1: User A has appropriate licenses for D365 and Power Platform. User A wants to distribute data from D365 to colleagues (unlicensed), who will modify the data. This modified data will be imported back to Dataverse. Do the colleagues require additional licensing?

Scenario 1

User A manually exports data from D365 and uploads it to an external storage location. The colleagues consume/edit the data in the external storage location. User A manually imports the data back to D365.

Not Multiplexing: Since User A is manually performing all steps in the distribution of data, and they have the appropriate licenses, it does not matter who they are sending data to. The colleagues are accessing & modifying the data in an external storage location, and D365/Power Platform licensing is not required for the colleagues.

Scenario 2

User A uses Power Platform to export data from D365 and uploads it to an external storage location. The colleagues consume/edit the data in the external storage location. User A uses Power Platform to import the modified data back to Dataverse.

Not Multiplexing: Power Platform is performing all the steps in data distribution (Indirect access), and typically users require this license at a minimum. User A has the appropriate application licenses to access the original data (D365) and import (D365 & Power Platform) back the modified data. Since the colleagues are not directly accessing the data in Power Platform or performing the upload, they do not require a D365 or Power Platform license.

Scenario 3

User A uses Power Platform to export data from D365 and send it to their colleagues. The colleagues edit the data in Power Platform. Power Platform imports the modified data back to Dataverse.

Multiplexing: Since the colleagues are accessing Power Platform, they require an appropriate Power Platform license. Since they are indirectly accessing & modifying the D365 data through Power Platform, they also require an appropriate D365 license.

Scenario 4

User A uses Power Platform to export data from D365 and send it to their colleagues. The colleagues only view the data in Power Platform, or export the data into another medium.

Multiplexing: Since the colleagues are accessing Power Platform, they require an appropriate Power license. Since they are only viewing the data, and not modifying, they do not require a D365 license.

Example 2: Customer uses Power Platform to solve a pain point, then buys Dynamics 365 and wants to deploy it in the same environment.

Power Platform can create significant advantages in productivity for customers. Occasionally customers prefer to “lock down” their Dynamics 365 environment to scenarios directly related to it – and therefore deploy more standalone scenarios in a different environment.

When deploying in the same environment, Multiplexing rules will still apply even with the Power Platform solution deployed and it’s critical that each user or device has the proper Dynamics 365 access licenses.

Example 3: Customer wants to extend their Dynamics 365 scenarios via Power Platform in the same environment.

This scenario is extremely common for customers who want to use Power Apps to extend Dynamics 365 for “light” Dynamics 365 scenarios that may have traditionally been covered in a Team Member scenario. For example, Firstline workers may want to use Power Platform for lead generation or customer support. With the added complexity of this workforce historically being unlicensed, introducing new automated solutions often causes additional licensing and scenario questions.

Multiplexing rules will still apply, and it is critical that each user or solution has the proper Power Platform license and Dynamics 365 access license depending on the solution deployed.

Example 4: Customer wants to extend their Dynamics 365 scenarios via Power Platform in the same environment and they want to create a separate Power Platform environment for standalone scenarios.

This is also a very common scenario – Dynamics 365 customers who want to do Example 2 usually (often model-driven apps) also want to create non-related solutions (often canvas-driven apps) that they’d like to keep separate for a variety of reasons (e.g. clean data, security/access control, etc.).

As with Examples 1 and 2, the same Multiplexing rules will still apply depending on the Power Platform solution deployed and each user or device must have the proper Dynamics 365 access licenses.

See more FAQs.

Dataverse

Microsoft Dataverse is a business application platform that easily structures data and business logic to support interconnected applications and processes. As such, Dataverse enables organizations to securely store, manage, and act on data used by business applications.

Direct versus Indirect Access to Dynamics 365

• Direct Access: means interacting with a Dynamics 365 application’s interface.
• Indirect Access: means to solely interact (Create, Read, Update or Delete) with Dynamics 365 data through a non-Dynamics 365 application, such as via a custom-built Power App or through Power Automate flows.

Dynamics 365

Dynamics 365 is a portfolio of intelligent business applications that delivers superior operational efficiency and breakthrough customer experiences enabling businesses to become more agile and reduce complexity without increasing costs.

Multiplexing

Multiplexing can be defined as hardware or software that is used to pool connections, reroute or indirectly access information, or reduce the number of devices or users that directly access or use the Product. It can also be classified as a way to reduce the number of OSEs, devices, or users the Product directly manages.

A key point to note, sometimes referred to as “pooling”, Multiplexing does not reduce the number of licenses of any type that a customer needs for their solutions.

Power Apps

Power Apps is a suite of apps, services, and connectors, as well as a data platform, that provides a rapid development environment to build custom apps for your business needs. Using Power Apps, you can quickly build custom business apps that connect to your data stored either in the underlying data platform (Microsoft Dataverse) or in various online and on-premises data sources (such as SharePoint, Microsoft 365, Dynamics 365, SQL Server, and so on).

Power Platform

The Power Platform is the collective group of Power Apps, Power BI, Power Pages, and Power Automate to customize, extend, and build all the apps you need for your business and unlock the potential of Microsoft 365 and Dynamics 365. The Power Platform is made possible by Microsoft Dataverse.