Licensing isn't just a procurement or finance concern. Whether someone can log in at all, and what they can do once inside, is governed by licensing — which makes it directly relevant to anyone working with the platform, developers included. This chapter skips specific prices, since pricing and packaging change too often for written content to stay accurate. What matters here is the concept: what a license controls, not what it costs today.
- A license controls who can log in and which apps/features they can use
- Licensing isn't a single yes/no switch — different tiers unlock different combinations
- A full user license fits people working in the apps every day
- Limited/lighter access fits people who mostly view records or do narrow tasks
- Adding users or access always has cost implications — developers included
A license is a key that opens specific doors
At the simplest level, a Dynamics 365 CE license does two things:
- Determines who is allowed to log in to an environment at all
- Determines which apps and features that person can use once they're in
Having a license isn't a single yes/no switch — different license types unlock different combinations of apps and capabilities. Someone licensed for Sales might not automatically get Customer Service; that typically needs its own license, or a broader one bundling several apps together.
The gym membership analogy
Quick analogy: licensing works like a gym membership. A basic membership gets you through the door and onto the cardio machines, but the pool, sauna, and group classes are locked behind a higher tier. Everyone has "a membership," but what it unlocks depends entirely on the tier they signed up for.
Dynamics 365 CE licensing works the same way. Being "licensed" doesn't mean unrestricted access to everything — it means access to whatever that specific tier includes. A higher tier might bundle in more apps, more automation capacity, or more advanced features.
Full users vs. more limited access
Not everyone in an organization needs the same level of access, and licensing reflects that.
- Full user license — for people who actively work inside the apps every day: creating and editing records, running processes, using the core functionality of Sales, Customer Service, or whichever app applies to their role
- Limited access types — for people who mostly need to view information or perform a narrow set of actions, rather than work in the system all day
The exact names and boundaries of these limited access types shift over time, but the underlying idea stays stable: not every person needs, or should pay for, the same level of access.
| Access type | Typical use |
|---|---|
| Full user license | People actively working in the apps daily — sales reps, support agents, and similar roles |
| Limited / lighter access | People who mostly need to view records or perform a narrow set of actions, rather than work in the system full-time |
Why this matters even if you're a developer
It's tempting for a developer to treat licensing as someone else's problem — a line item a manager or procurement team worries about. But it matters directly to how you build things:
- You can't add more users to an environment without cost implications
- Should an automated process run under its own dedicated account instead of a person's login?
- Does a new integration need its own type of access?
A developer who understands what licensing controls builds solutions that fit an organization's actual access model, instead of assuming everyone can be added freely or that every user automatically has access to every app.