What is Multiplexing?
In Microsoft licensing terms, multiplexing refers to using hardware or software that pools connections, reroutes information, or reduces the number of devices or users that directly access or use a Microsoft product.
The core principle is simple: indirect access still requires licensing. If a human will ultimately use the data or functionality, they need a license—even if they never log into D365 directly.
Think of it this way: A receptionist doesn't log into D365. But they use a web portal that your company built. That portal queries D365 to check customer information, create service cases, or confirm order status. The receptionist is indirectly accessing D365. They need a license.
Why This Matters for Dynamics 365
Multiplexing licensing violations are expensive and risky for D365 deployments because:
- Microsoft conducts regular audits. Not just software audits—usage audits. They review your access logs, integration patterns, and user behavior.
- Back-pay is substantial. If you're audited and found non-compliant, you pay retroactively—often 2–3 years. Multiplied by the number of unlicensed users.
- D365 is an enterprise system. It touches Finance, Supply Chain, Sales, Customer Service, HR. The exposure is broad. One unaudited integration can implicate dozens of users.
- Integration architectures are complex. Middleware, portals, Power Automate flows—there are a dozen ways to indirectly access D365. Most teams don't track them all.
Common Multiplexing Scenarios in D365
1. Portals and Custom Web Apps
You build a customer portal in Power Apps or a custom ASP.NET web app. Customers log in, check their orders, create support tickets, or upload documents. The portal reads and writes to D365.
Multiplexing question: Does every customer need a license? No—but here's the catch: if a customer is also an employee, a vendor, or part of your supply chain, they might need a D365 license for that role. If they're pure external customers, it depends on your licensing agreement.
Safe approach: External customer portals typically fall under your D365 infrastructure costs, not per-user licensing. But verify with your Microsoft licensing rep. Document your architecture.
2. Power Automate Flows Creating Records on Behalf of Users
A non-licensed user submits a form on your intranet. A Power Automate flow catches that submission and creates a D365 record (invoice, order, case) on behalf of that user. The user never touches D365 directly.
Multiplexing question: Does the user need a license? Often yes. They're using D365 functionality indirectly—the flow is just the vehicle.
The gray area: If the flow is system-triggered (scheduled, event-based) and not human-initiated, it might be okay. If a human submits a form that triggers it, the human likely needs a license.
3. Middleware and Integration Layers
You have a warehouse management system (WMS) or EDI system that pushes inventory data, orders, or ASNs into D365. A procurement clerk uses the WMS—they never open D365—but D365 reflects all their work.
Multiplexing question: Does the procurement clerk need a D365 license? Technically, yes, if their actions in the WMS result in D365 records that a human benefits from. But in practice, this is often treated as a system-to-system integration with no human-triggered multiplexing.
The distinction: Pure system integrations (batch jobs, API calls on a schedule) are usually safe. Human-triggered actions flowing through middleware to D365 need licensing for the human.
4. Receptionist or Shared Workstation Scenario
Your reception area has one shared computer. Three receptionists take turns using it. It's logged into D365 with one shared account to check customer records and create service cases.
Multiplexing question: Do you need three D365 licenses or one? You need three. Each person using the system, even if it's the same device, needs their own license.
Why: D365 licensing is per-user, not per-device. The fact that they share a computer doesn't reduce your licensing burden.
5. Customer-Facing Apps Querying D365 Backend
You've built a mobile app for suppliers or distributors. It queries D365 for real-time inventory, pricing, or shipment status. They're not in D365 themselves—they're in your app.
Multiplexing question: Do they need licenses? Not always. If the app is read-only and the user isn't logged into D365, you might be okay. But if the app allows them to place orders, submit claims, or trigger workflows in D365, they probably do.
Safe approach: Treat read-only data access differently from transactional access. Provide service accounts or integration accounts for queries. For transactional user-triggered actions, ensure users are licensed appropriately (often Team Member licenses or Power Platform licenses, depending on the scenario).
What ISN'T Multiplexing
Legitimate Service Accounts
You have a service account in D365 that only runs automated batch jobs, scheduled integrations, or system-generated workflows. No human is logging in as this account. No human is indirectly benefiting from it in a way that would trigger licensing.
This is okay. Service accounts don't need per-user licensing if they're truly system-only. But document what they do.
System-to-System Integrations with No Human Trigger
Your ERP pushes daily GL transactions into D365 Finance via an API. Your HR system syncs employee records into D365. No human is actively using the integration. It's scheduled or event-driven, but not human-triggered.
This is okay. These are infrastructure-level integrations, not multiplexing. But verify the data doesn't flow back to human-facing applications that would require licensing.
Batch Processes and Report Generation
A scheduled job runs every night, pulls D365 data, and generates reports. The reports are distributed to stakeholders who read them but don't interact with D365.
This is probably okay. Passive consumption of data (reports, dashboards, summaries) is usually not multiplexing. But if the report allows editing, commenting, or triggering actions in D365, reconsider.
License Types: Which Applies to Your Scenario?
Understanding D365 license types helps clarify when multiplexing matters:
| License Type | Who Uses It | Best For | Direct or Indirect? |
|---|---|---|---|
| Full User (F&SCM, Sales, etc.) | Users who work in D365 daily. Full access. | Finance teams, supply chain planners, sales reps, service agents. | Direct access. Per-user cost. |
| Team Member | Users who need D365 access but limited functionality. Read + limited create/edit. | Occasional users, support staff, managers needing visibility. | Direct access. Cheaper per-user cost. |
| Device License | Multiple users sharing a device. | Shared workstations, kiosks, reception areas. | Direct access. Per-device cost. Actually requires per-user licenses on top. |
| Power Platform (Premium) | Users accessing D365 via Power Apps, Portals, or integrations. | Portal users, app-based access, indirect access scenarios. | Can be indirect. Depends on use case. |
| Free/Light Experience | Very limited access. Basic read and comment functionality. | External stakeholders, view-only access. | Usually direct (minimal) or not multiplexing. |
How Microsoft Audits for Multiplexing
Microsoft's audit process is systematic and thorough:
- License entitlements vs. active users: They reconcile what you're licensed for vs. who's actually logging in. If you have 50 full users licensed but 100 people logging in daily, that's a red flag.
- Access logs and usage patterns: They review login history, API activity, and Power Automate execution logs. They look for suspicious patterns: shared accounts, service accounts logging in from many IPs, or accounts accessing data outside their normal role.
- Integration architecture review: They ask how data flows. If you have portals, Power Automate flows, or middleware, they drill into whether those are multiplexing unauthorized users.
- Power Automate audit: They review flow action logs to see if flows are creating or modifying records on behalf of unlicensed users.
- Licensing agreement cross-check: They verify you're using the right license types for your scenarios. If you're using Team Member licenses for full-time sales reps, that's non-compliance.
Practical Steps to Stay Compliant
1. Audit Your Integration Landscape
Make a list of every system touching D365: portals, Power Automate flows, middleware, APIs, reports. Don't guess. Actually document it.
For each integration, ask: Is a human triggering this? Is a human benefiting from the result? If yes to either, is that human licensed?
2. Map Every Human Touchpoint
Identify every person who interacts with D365, directly or indirectly. Include:
- Direct D365 users
- Portal users
- Mobile app users
- People submitting forms that trigger workflows
- External vendors or customers querying your system
Assign each person a license category: Full User, Team Member, Power Platform, Free/Light, or no license (if truly no D365 access).
3. Use Team Member Licenses Appropriately
Many compliance gaps come from over-licensing. If a user only needs to read data or occasionally create one record type, Team Member might be enough. Audit your current licensees—you might reduce costs while improving compliance.
4. Document Your Architecture for Audit Defense
When Microsoft audits, they want to see a clean, documented architecture. Create a document describing:
- Your D365 licensing model (how many of each license type, why)
- Integration touchpoints (portals, flows, APIs)
- User role to license mapping
- Data flow diagrams (especially for multiplexing-prone scenarios)
- Service accounts and their purpose
Even if there are gaps, showing that you've thought through compliance is better than no documentation at all.
5. Review Power Automate Flows for Compliance
This is urgent. Go through your critical Power Automate flows and check:
- Does the flow create, update, or delete D365 records?
- Is a human trigger involved (form submission, button click, approval request)?
- Is the person triggering the flow licensed appropriately?
If the answer to all three is yes and the person isn't licensed, flag it for remediation.
The Gray Areas (Where Even Microsoft's Guidance Isn't Clear)
Shared Portal Access
You have an external vendor portal. Twenty different vendors use it, but the portal itself is one licensed entity. Do all 20 vendors need licenses, or does your company?
Microsoft's answer: Technically, the vendors might, but if they're external and the portal is read-only, you're usually okay under Power Platform licensing. If they're internal employees wearing a "vendor hat," they need D365 licenses.
Bottom line: Ask your Microsoft licensing rep specifically about your scenario.
Power Automate + D365 + Power Apps
A user has a Power Apps license. They use a Power App that triggers a Power Automate flow that reads/writes D365 data. Do they need a D365 license too?
Microsoft's answer: Not necessarily. Power Platform licenses can cover indirect D365 access in some scenarios. But context matters: what's the app doing? How much D365 data? Is it transactional or read-only?
Bottom line: This is evolving. Current guidance favors Power Platform licenses for portal and app-based access, but there's overlap with D365 licensing. Clarify with your rep.
Vendors Accessing Your System
Your supply chain is integrated with vendor EDI systems. They push purchase orders and shipments into D365. Do they need licenses?
Microsoft's answer: No, if it's system-to-system with no human-logged-in access. Yes, if a vendor portal or human-triggered process in your system lets them interact with D365.
Bottom line: Be clear about the flow. Pure API integrations are usually fine. Human-accessed portals require licensing decisions.
Caf2Code's Take: Multiplexing Compliance is Underestimated
The compliance fix isn't hard if you catch it early. But retroactive back-pay for undisclosed users across 2–3 years is brutal.
Our recommendation: Schedule a licensing audit now, not after an audit trigger. Most companies find 10–20% of their actual users aren't properly licensed. Some find serious gaps. Better to discover and fix it on your terms than wait for Microsoft's letter.
The cost to audit and remediate proactively is a fraction of the cost to remediate after a compliance audit. And you'll have documented proof of due diligence, which helps in any future negotiation with Microsoft.
Key Takeaways
- Multiplexing is about human access, not technology. If a human uses D365 indirectly—through a portal, app, workflow, or integration—they need to be licensed.
- Common gaps: Customer portals, Power Automate flows creating records, vendor access, shared workstations. These are audit targets.
- Documentation is your defense. Prove you've thought through licensing. Have an architecture diagram and a user-to-license-type mapping.
- Audit now, not later. Proactive compliance fixes are cheaper and less disruptive than retroactive remediation.
- Power Platform and D365 licensing are converging. Portal and app-based access can be licensed under either umbrella. Clarify your specific scenario with Microsoft.