The first layer: licenses (entitlements)
Microsoft calls the rights that come with a license “entitlements”. Entitlements describe which objects in Business Central a user is entitled to use, based on the license they have or their Microsoft Entra role. Think of them as the outer boundary of what a user could ever do.
The current license types for Business Central online are:
- Essentials. A full user license for core areas such as finance, sales and purchasing.
- Premium. Everything in Essentials, plus Service Management and Manufacturing.
- Team Member. A light license, mostly read access plus a limited set of tasks, such as approvals and time sheet entries.
- External Accountant. A license intended for the company’s external accountant.
- Device. For shared devices such as a point of sale, shop floor or warehouse terminal, used by several people. A device user cannot be the first user to sign in to a new environment.
- Microsoft 365 license. Read-only access to Business Central data, as an addition to an Essentials or Premium subscription, for example when records are shared in Microsoft Teams.
How licenses and permissions combine
When a user signs in, Business Central applies the intersection of the entitlements from their license and the permissions you assigned. Microsoft is explicit that entitlements always win.
Microsoft’s own example makes the point: even if an admin gives a user the SUPER permission set, a user with a Team Member license can still only access the objects that the Team Member entitlements allow. The other way around, a user with an Essentials license and SUPER can do far more than a Team Member with SUPER.
So a license can never be stretched by a permission set. But a permission set can, and should, narrow what a license allows.
The SaaS vs. on-premises logic
The way licenses are enforced depends on your deployment:
- Online (SaaS). Business Central online does not use the classic license files. Business Central reads the user’s service plan from Microsoft Entra ID and loads the matching entitlements. Your permission sets then decide what the user can do within those limits.
- On-premises. On-premises installations still work with a license file, which determines which objects are available in the solution. Objects outside that license are not accessible, whatever the permission sets say.
The differences go further than this, especially for extensions and custom objects. We cover them in detail in our post on the hidden differences in permission logic between SaaS and on-premises.
The second layer: permission sets (the keys)
While a license sets what a user could do, permission sets determine what they may do.
Even with a Premium license, you would not want a warehouse employee to reach the general ledger or payroll data. Permission sets let you define access per object, for five access types:
- Read. Can the user see the data?
- Insert. Can they create new records?
- Modify. Can they change existing records?
- Delete. Can they remove records?
- Execute. Can they run a page, report or codeunit?
Each access type can be set to Yes, to Indirect (the user can only perform the action through another object, such as a posting routine) or left blank. Indirect permissions are what let a user post a sales order without having direct edit rights on the underlying ledger tables.
Admins can also configure which permission sets and security groups a user gets by default for each license. The Team Member license, for example, comes with sets such as D365 READ and D365 TEAM MEMBER by default. Security groups, based on Microsoft Entra groups, have replaced the legacy user groups for assigning permission sets to many users at once.
Why entitlements aren’t enough
Relying on licenses alone for security leaves the scope far too broad. If you only managed users through licenses, every Essentials user would effectively be a super user within the areas their license covers.
The risks of poor permission management:
- Data exposure. Users can see sensitive financial or personal data they do not need for their job.
- Human error. An employee deletes a critical record because they had delete rights they never needed.
- Compliance findings. In an IT audit, over-privileged users are a red flag for fraud risk and weak segregation of duties.
Check what users actually have
Because access is the result of two layers, it is easy to lose track. The Effective Permissions page, opened from the user, shows the permissions a user ends up with and the source of each one. Rows with the source Entitlement come from the license; the others come from permission sets or security groups.
Since BC28, the Permissions Overview page also shows permission sets, security groups and assignments across apps in one view. Both help you check the result. Neither one assigns, approves or reviews access for you.
Conclusion: finding the balance
Effective authorization management in Business Central takes two steps:
- Assign the right license, so the user has the technical capability to do their job.
- Build a modular permission set structure that limits access to the tables, pages and reports the user actually needs.
Keeping these two concepts apart keeps your organization in control, protecting your data while letting your team work efficiently.
Want to learn more about structuring permissions efficiently? Download our whitepaper “Authorizations in Business Central”, or see how Authorization Box helps you set up and manage permission sets through an organization chart of departments and roles.
Frequently asked questions:
Related reading:
- SaaS vs. on-premises: the hidden differences in permission logic
- Business central permission sets explained
- SUPER, the dreaded permission set in Dynamics 365 Business Central
- What is happening to User Groups and how to transition to Security Groups?
- Building a Permissions Framework: Why an Org Chart is Step One for Security