Multiplexing is the rule that says a person who reaches Dynamics 365 data through an intermediary still needs a license, even when they never open a Dynamics screen. A portal, a custom front end, an integration that writes orders into the system, a reporting layer that pulls Dynamics records: each of these can route hundreds of unlicensed people into licensable scope without anyone provisioning a single seat. This is the exposure that surprises estates the most, because the named user count looks clean while the real population of people benefiting from Dynamics data is many times larger. An auditor does not count seats. The auditor counts the humans who consume the output, and the gap between those two numbers is where multiplexing assessments land their largest findings. The defensible position is to map every path into Dynamics before that map is drawn for you.
Microsoft licenses Dynamics 365 by the user, not by the connection. The principle behind multiplexing is that licensing follows the person who benefits from the data, no matter how many layers of software sit between that person and the database. Pooling access through middleware does not reduce the number of licenses required.
If a person reads, enters, or acts on Dynamics data, that person needs a license even if a portal, an application, or an automated process performs the actual transaction on their behalf. The intermediary does not absorb the license requirement. It passes the requirement through to the human at the end of the chain.
Estates measure their Dynamics exposure by the named user list in the admin center. That list captures only the people provisioned directly. It says nothing about the customer service portal feeding cases into Dynamics, the warehouse scanner writing inventory movements, or the finance team reading Dynamics figures through a third party report.
Multiplexing risk concentrates in a handful of architecture patterns. Each one moves Dynamics data to people who never log in, and each one is read the same way under a licensing review. Knowing where to look is most of the work.
A company builds a branded portal that lets staff or partners submit requests, check status, or update records, with Dynamics as the database behind it. Every person using that portal is an indirect Dynamics user. The portal does not hold the license. The people do. This is the single most common source of large multiplexing findings, because a portal can serve a population an order of magnitude larger than the directly provisioned team.
An order management system, an ecommerce platform, or an ERP writes records into Dynamics through an integration account. The integration account is not the user. The people whose work flows through that integration are the users. Where the upstream system is operated by humans who rely on the Dynamics outcome, those humans fall into scope, and the service account that brokers the data does not change that.
A Power BI workspace, a data warehouse, or a third party reporting tool extracts Dynamics data and presents it to a wide audience. Pure consumption of static, exported reports sits in a more nuanced position than live interaction, but the moment the reporting layer offers drill through to live records or write back, the audience moves into licensable territory. The boundary between reading a static extract and interacting with live data is exactly where these assessments probe.
A chatbot answers customer questions from Dynamics data, or an automated process creates and updates records triggered by user actions elsewhere. Automation that acts on behalf of identifiable people carries those people into scope. The convenience of a single service identity running thousands of operations is precisely what makes this path quiet until it is assessed.
The defensible position is not to assume the worst and license everyone, nor to assume the best and license no one beyond the seat list. It is to map every path into Dynamics, classify the population on each path, and license to the real picture before an audit constructs that picture for you and attaches back payment to it.
We inventory every portal, integration, reporting feed, and automation that touches Dynamics, then trace each one to the human population it serves. This produces the number that actually matters: not how many people are provisioned, but how many people benefit from the data. In most estates this number is materially larger than the seat list, and quantifying it is the first time leadership sees the true scope rather than the administrative one.
Not every indirect user needs a full Dynamics license. Many fit the team member tier, some sit genuinely outside scope on pure static consumption, and a portion need full users. We classify each population to the correct license, which often means the corrected exposure costs far less than a blanket full user assumption would suggest. The goal is a position that is both honest and as cheap as honesty allows, documented so it survives the review rather than collapsing under it.
The four access paths that create indirect users, how each one is read under a licensing review, and the classification approach that prices the real population to the correct tier. Sent on request.
We trace every portal, integration, report, and automation that touches Dynamics, count the real population each one serves, and license that population to the correct tier. The result is a documented multiplexing position that holds up under review rather than becoming the largest line in a settlement.