Business Central entitlements explained

Were you ever surprised to see “You dont have permissions…” message for a specific Business Central object, while you were sure you had permission to run it (“I even get it if I assign SUPER permission!!”? Then please read further to learn about the underlying authorization logic we employ in the Business Central online service and become better equipped to troubleshoot and report permissions issues in the future.

In Dynamics 365 Business Central online, we use two levels of permissions for the application objects:

• Permissions that describe which objects a customer is entitled to use according to their Azure Active Directory role or the license they purchased from Microsoft
  • This type of permission is called entitlements in Business Central online
• Permissions that describe which objects an administrator or a partner gave the customer access to inside Business Central
  • This type of permission is (still) called permissions in Business Central online and on-premises

Entitlements

In Business Central on-premises, the first category of permissions is implemented in a license file (*.flf). The license file contains per-object definition of the access, matching what the customer has purchased. In Business Central online, the license file (*.flf) is not used for defining purchased access to the objects, instead we use the entitlements. Naturally, in the cloud world, the entitlements cannot be edited neither by our partners, nor by our customers – they are defined and maintained by Microsoft. If you want to study which entitlements are given for a specific license or Azure Active Directory (Azure AD) role when working with Business Central online, you can inspect the entitlements in the standard demo database that we ship with the on-premises versions and via Docker.

The entitlements are stored in the Entitlement table in the application database. Entitlements are then grouped into entitlement sets which can be found in the Entitlement Set table.

The entitlement sets in their turn are linked to the Azure AD service plans which correspond to the purchased license, or to specific Azure AD roles (memberships).  The mapping between the service plans, roles and entitlement sets is defined in the Membership Entitlement table.

The service plans are registered for the users in Azure AD when the license is assigned to them in the Microsoft 365 admin center (replaces the Office 365 admin center):

As an admin of the Azure AD tenant, you can also look up the service plan that is assigned to the user programmatically via the Azure AD Graph API:

The following are the standard Dynamics 365 Business Central service plans:

In terms of accessing Business Central by Azure AD role membership (without a license) – the Global administrator role is the only internal Azure AD role that has access to Business Central.  Users with Admin agent and Helpdesk agent roles also don’t require a license, these roles are assigned through CSP via the Partner Center and used by the partners for support purposes (delegated admins). These roles are also limited by the entitlements, and you can see which entitlements are applied to them by looking into the Membership Entitlement table (entries for NAV_INTERNAL_ADMIN, NAV_DELEGATED_ADMIN and NAV_HELPDESK).

The User Group Plan table in the tenant database stores the mapping between the service plans and the user groups. Based on this mapping, the service determines which user group is assigned to a user by default when a user logs in to Business Central for the first time. The user group assigns a specific license (or makes the user a member of a specific Azure AD role):

The User Plan table in the tenant database is populated automatically with the user ID and the service plan that was detected for them during login.

When a user logs in to Business Central, the service applies the intersection of the entitlements that are associated with the user’s service plan (or Azure AD role) and the permissions that are defined for that user. Entitlements always have higher priority over permissions. For example, even is the user is given SUPER permissions by the admin but has the Team Member license assigned – the user can still only access the objects defined by the Team Member entitlements.

Now you know how the entitlements look like internally in our service and how they are used to manage user access to the Business Central objects. As the end user – you can also analyze both permissions and entitlements assigned for each object using the Effective Permissions page, which is accessible from the User card:

The entitlements in Business Central are defined only for the application objects in the Microsoft ID range.

The objects in the ISV partner ID range that are brought in through the AppSource extensions, and the objects in the 50000+ range that come from per-tenant extensions are not managed by Microsoft entitlements and therefore fully accessible with any Microsoft license. You, as a partner, should therefore ensure that the access to your objects is regulated through the Business Central permissions or self-monetization techniques.

Make sure you also read Working with Sandboxes and Entitlements article, which provides an overview of the user groups assigned to the users by the service, according to their license or AAD group membership. The article also explains peculiarities of working with our Docker images and sandboxes, where entitlements and permissions work a little bit differently.

Dmitry Chadayev

See more articles from this author