The practical answer
Dynamics 365 licensing follows what each named user does, not only which application tile or security role an administrator gives them. A compliant design starts with the user’s activities across all Dynamics applications, applies the correct base-and-attach order, and treats Team Members and indirect access as specific rules—not general discounts. Microsoft’s current Dynamics 365 licensing guide is the decisive feature-use-rights reference. Because the guide changes, build the entitlement matrix against its current edition at purchase and renewal.
Base and attach in plain English
When one user needs multiple qualifying Dynamics 365 applications, the first application is licensed at the full base price. Additional eligible applications can be licensed with lower-priced attach licences.
Licence the user, not the security role
Security roles control what a user can do technically. They do not create licensing entitlement.
What the Team Members licence is for
Dynamics 365 Team Members is a named-user licence for designated lightweight scenarios. Microsoft describes it for employees who consume data or complete limited tasks but do not need the full functional application.
Base and attach in plain English
When one user needs multiple qualifying Dynamics 365 applications, the first application is licensed at the full base price. Additional eligible applications can be licensed with lower-priced attach licences.
- The base licence is not simply whichever product the customer prefers to call primary. Microsoft defines eligible base/attach combinations and ordering rules. The
- user must have a qualifying base before an attach licence is valid, and each application’s use must remain within its licensed rights.
- For example, a person who performs substantial Sales and Customer Service work may need a full qualifying base application plus the permitted attach. Another
- employee with only Sales activity needs only the appropriate Sales licence. Do not assign attach licences to users without confirming the base prerequisite.
Licence the user, not the security role
Security roles control what a user can do technically. They do not create licensing entitlement. A customised role that grants access to a restricted table or operation still requires the relevant licence. The reverse matters too: assigning a full licence does not automatically give the user application access. Administrators still need the correct environment access, security role, app assignment, and data permissions. Build two mappings and reconcile them: Entitlement map: which product rights the user needs. Access map: which applications, tables, operations, roles, and integrations the user can reach. If access exceeds entitlement, reduce access or upgrade the licence. If entitlement substantially exceeds use, investigate optimisation at the next allowed commercial change point.
What the Team Members licence is for
Dynamics 365 Team Members is a named-user licence for designated lightweight scenarios. Microsoft describes it for employees who consume data or complete limited tasks but do not need the full functional application.
- For customer-engagement workloads, the supported experience uses designated apps such as Sales Team Member, Customer Service Team Member, and Project Resource Hub. The current licensing guide defines the actual use rights.
- Team Members is not a licence for unrestricted use of Sales Hub, Customer Service Hub, or a custom model-driven application. Microsoft’s Learn documentation
- states that it does not provide access to custom applications and is not intended for scenarios beyond those listed in the licensing guide.
- Technical enforcement may not catch every non-conforming table operation. The ability to grant a privilege or complete an action is not proof that the Team Members licence permits it.
When Power Apps may be relevant
If a user needs a custom application rather than a Dynamics 365 first-party application, Power Apps licensing may be appropriate. But a Power Apps licence cannot be used to obtain restricted Dynamics 365 application rights through a custom interface. Check restricted tables and the current Power Apps and Dynamics licensing rules. The correct answer depends on whether the application extends a licensed Dynamics workload or independently uses Dataverse and custom data.
Multiplexing and indirect access
Multiplexing is the use of hardware, software, automation, portals, shared interfaces, or pooled connections to reduce the number of direct connections to Dynamics 365. Microsoft’s multiplexing guidance makes the core rule clear: multiplexing does not reduce the number of required licences. If users submit, retrieve, update, or otherwise benefit from Dynamics functionality indirectly through another application, integration, robotic process, shared service account, or data layer, they can still require the appropriate licences. The front end does not erase the underlying access.
- Examples that deserve review include: a custom portal that writes customer-service records into Dataverse;
- an ERP integration triggered by many unlicensed employees;
- shared service accounts used to pool user transactions; Power Automate flows that perform premium actions for users;
- exported Dynamics data placed in a reporting or collaboration system; bots or agents that create or update records on behalf of people.
Practical checks
Not every data export or automated system is automatically multiplexing. Identify who initiates the process, who receives the value, which system performs the restricted operation, and which current product terms apply. Document the conclusion rather than using a blanket rule.
A user-activity workshop
For every persona, list the real activities in business language: create or qualify leads;
- manage opportunities and forecasts; create, update, or resolve cases;
- schedule or complete field work; approve finance or supply-chain transactions;
- enter time or expenses; read reports or records;
- use a custom app or portal; trigger an integration or automation.
Practical checks
Map each activity to the current licensing guide, then select the qualifying base, attach, Team Members, Power Apps, device, or other licence. Validate the result against security roles and telemetry.
Common mistakes
Assigning an attach licence without a qualifying base. Choosing the base only by price rather than Microsoft’s ordering rules.
- Using Team Members for full application or custom-app access.
- Treating a security role as a licence definition.
- Pooling access through a service account or integration to reduce user counts. Assuming data moved outside Dynamics can be used in every downstream scenario without review.
- Licensing the integration owner but ignoring the people who initiate or benefit from it.
Practical checks
Relying on technical enforcement instead of the licensing guide.
Ongoing governance
Review active users, assigned licences, app access, security roles,
- non-conformant usage reports, integrations, and service accounts at least
- quarterly. Remove licences from genuinely inactive users following the commercial rules, and update users whose roles changed.
- At renewal, re-read the current Dynamics 365 licensing guide. Product packaging,
- attach eligibility, use rights, and enforcement can change between editions.
Practical checks
For an activity-based Dynamics licence assessment, contact Axeti . The same evidence can feed a wider Microsoft licensing governance process.
Sources and scope: This article is based on Microsoft’s current Dynamics 365 licensing and multiplexing documents and Team Members overview . The current licensing guide and applicable Product Terms control; revalidate every user activity and base/attach combination before purchase, deployment, or renewal.
