The Dynamics 365 team member license costs a small fraction of a full user license, which makes it the most attractive option on the price list and the most frequently misapplied one in the estate. It is built for genuinely light users who read records and perform a narrow set of bounded tasks, and its rights are deliberately constrained to that profile. The temptation is to license broadly on it to cut the bill, but the constraints are real and an audit tests them precisely. The two failure modes sit on opposite sides of the same line. Estates that put real power users on team member licenses to save money carry a compliance exposure that surfaces the moment an auditor checks what those users actually do. Estates that keep light users on full user licenses out of caution overpay every year for entitlements those users never touch. The right call is a usage based judgment about where each user genuinely sits, not a blanket policy in either direction.
The team member and full user licenses are not the same product at different prices. They grant different rights, and the price gap reflects a genuine difference in what the user is allowed to do. Choosing correctly starts with reading what each one entitles.
The team member license grants read access across applications and a deliberately narrow set of write tasks, such as updating records the user owns, entering time and expense, or participating in defined self service scenarios. It is priced for users whose interaction with Dynamics is occasional and shallow, and its rights stop well short of operating an application.
The full user license grants the rights to actually run an application: working opportunities and cases, managing records others own, configuring and using the application's core capabilities. Any user whose job is to operate Dynamics rather than glance at it belongs on a full user, base or attach, regardless of how often they log in.
The decision is not about login frequency or job title. It is about what the user does inside the application. Three usage signals reliably indicate a user has crossed from team member territory into full user territory, regardless of how light their use feels.
The clearest signal. A user who updates, reassigns, or progresses records they do not own is operating the application, not reading it. Team member write rights are confined to the user's own records and the named self service tasks. The moment a user touches a colleague's case or opportunity, the team member license no longer covers them.
A user who runs a sales pipeline, resolves service cases, or executes a finance workflow is using the application's core capabilities. These are full user rights by definition. The fact that the user does it for only a handful of records a week does not change the license they require, because the right is about capability accessed, not volume.
Access to a custom application built on the restricted Dynamics tables requires full user rights even when the interface looks simple. Estates often build a lightweight custom app, assume team member licensing covers it because the screen is basic, and miss that the underlying tables put every user of that app into full user scope.
The correct position places every user on the cheaper team member license where their usage genuinely fits it and moves the users whose usage has crossed the line onto a full user before an auditor finds them. Both directions matter, because a one sided policy either overpays or creates exposure.
We pull the actual in application activity of every full user and identify those whose usage sits entirely within team member rights: read access, updates to their own records, and the bounded self service tasks. Those users step down to the team member license, which costs a small fraction of the full user they currently hold. Across a large population provisioned with full users by default at onboarding, this step down is a direct and recurring saving, often a meaningful slice of the Dynamics user line that no one revisited once roles settled.
The exposure runs the other way. Team member users who work records they do not own, run a core process, or use a custom app on restricted tables have crossed into full user scope and need the correct license before a Dynamics review finds them. We surface these users from the same activity data and move them up deliberately, on your terms, rather than letting them become a finding with back payment attached. The point is a user base where every license matches what the user actually does, which is both the cheapest defensible position and the one that survives the audit.
What each license permits, the three usage signals that push a user over the line, and the activity based review that right sizes the population in both directions. Sent on request.
We review the in application activity of the whole Dynamics population, step the genuinely light users down to team member licenses, and move the power users hiding on team member licenses up to full users before an audit reaches them. The result is the cheapest user position that still survives a Dynamics licensing review.