9.2 Inherent Permissions, Inherent Entitlements & Security Scoping

9.2 Inherent Permissions, Inherent Entitlements & Security Scoping

In modern Dynamics 365 Business Central development, managing security exclusively through external permission sets assigned to individual user accounts introduces severe administrative overhead, potential security vulnerabilities, and frequent licensing friction. When background routines, automated telemetry logging, preference caching, or ISV extensions require temporary access to restricted tables, granting broad permissions to all interactive end users violates the fundamental principle of least privilege.

To overcome these architectural constraints, AL introduces three powerful modern security constructs: the InherentPermissions attribute, the InherentEntitlements attribute, and first-class entitlement objects. For developers preparing for the MB-820 certification exam, mastering how these mechanisms interact with standard user permissions and Microsoft commercial licensing boundaries is critical for Domain 3.

1. The InherentPermissions Attribute Architecture

The [InherentPermissions] attribute allows an AL procedure or an entire object (Codeunit, Table, Page, Report, Query) to be granted elevated permissions to TableData or objects for the exact duration of that procedure's execution, regardless of whether the running user has those permissions assigned in their permission sets.

Procedure-Level vs. Object-Level Inherent Permissions

Inherent permissions can be declared at either the object level (in the object header) or the procedure level (as an attribute):

codeunit 50105 "Loyalty Processing Engine"
{
    // Object-level inherent permissions: grants read access across all procedures in this codeunit
    InherentPermissions = tabledata "Loyalty Member" = r;

    // Procedure-level inherent permission: grants temporary elevated CRUD rights
    [InherentPermissions(PermissionObjectType::TableData, Database::"Loyalty Ledger Entry", 'rimd', InherentPermissionsScope::Both)]
    procedure RecordTransactionPoints(MemberNo: Code[20]; PointsToAdd: Decimal)
    var
        LoyaltyLedgerEntry: Record "Loyalty Ledger Entry";
    begin
        LoyaltyLedgerEntry.Init();
        LoyaltyLedgerEntry."Entry No." := 0;
        LoyaltyLedgerEntry."Member No." := MemberNo;
        LoyaltyLedgerEntry."Points Added" := PointsToAdd;
        LoyaltyLedgerEntry."Posting Date" := Today();
        LoyaltyLedgerEntry.Insert(true);
    end;

    [InherentPermissions(PermissionObjectType::TableData, Database::"Audit Log Entry", 'i', InherentPermissionsScope::Cloud)]
    local procedure WriteAuditTrace(TraceMessage: Text[250])
    var
        AuditLog: Record "Audit Log Entry";
    begin
        AuditLog.Init();
        AuditLog."Log ID" := CreateGuid();
        AuditLog."Message" := TraceMessage;
        AuditLog."Timestamp" := CurrentDateTime();
        AuditLog.Insert(true);
    end;
}

Attribute Parameters Breakdown

Architectural Comparison: Inherent Permissions vs. Object Header Permissions

Why Use InherentPermissions?

1. Enforces Least Privilege: Users do not need direct or indirect table access assigned to their user accounts just because a routine logs an event or reads an internal cache.
2. Encapsulates Database Access: Direct table manipulation from outside the procedure is impossible; modifications can only occur when routed through the validated business logic of that procedure.
3. Eliminates Permission Bloat: Administrators no longer need to manage sprawling permission sets containing hundreds of internal setup and log tables.

2. Permissions vs. Entitlements & InherentEntitlements

Understanding the fundamental distinction between User Permissions and License Entitlements is critical for enterprise AL development and is heavily emphasized on the MB-820 certification exam:

• User Permissions: Configured by the tenant system administrator in the Business Central Web Client. They dictate what a specific user is authorized to do within their business organization based on assigned roles.
• License Entitlements: Dictated by the customer's Microsoft commercial subscription plan (such as Dynamics 365 Business Central Essential, Premium, Team Member, Device, or External Accountant). Entitlements define the maximum legal and technical capabilities permitted by Microsoft licensing.

The Cardinal Licensing Rule: A user's effective permissions can never exceed their license entitlements. Even if an administrator assigns the SUPER permission set to a user with a Team Member license, the runtime engine restricts that user from posting general journals, modifying warehouse shipments, or altering core master data because the Team Member entitlement strictly limits write operations.

The InherentEntitlements Attribute

When an extension needs to perform background operations—such as writing an application telemetry entry, reading extension configuration settings, caching user UI filter preferences, or updating a shared license counter—on behalf of a user who holds a restrictive license (such as a Team Member or Device license), standard permissions and even [InherentPermissions] fail if the operation violates the user's license entitlement ceiling.

The [InherentEntitlements] attribute elevates the license entitlement boundary for that specific procedure or object, allowing authorized background code to execute on behalf of any licensed user.

codeunit 50106 "User Preference Sync"
{
    [InherentEntitlements(PermissionObjectType::TableData, Database::"Extension User Setup", 'rimd', InherentEntitlementsScope::Both)]
    procedure SaveUserTheme(ThemeCode: Code[20])
    var
        UserSetup: Record "Extension User Setup";
    begin
        if not UserSetup.Get(UserSecurityId()) then begin
            UserSetup.Init();
            UserSetup."User Security ID" := UserSecurityId();
            UserSetup."Selected Theme" := ThemeCode;
            UserSetup.Insert(true);
        end else begin
            UserSetup."Selected Theme" := ThemeCode;
            UserSetup.Modify(true);
        end;
    end;
}

Inherent Entitlements Scoping

Like inherent permissions, [InherentEntitlements] supports scoping via InherentEntitlementsScope:

• InherentEntitlementsScope::Both: Active across both Business Central SaaS (cloud) and On-Premises environments.
• InherentEntitlementsScope::Cloud: Active strictly in Business Central Online (SaaS) environments.
• InherentEntitlementsScope::OnPrem: Active strictly in on-premises server deployments.

Scoping Matrix & Best Practices

3. AL Entitlement Objects (entitlement)

An entitlement object in AL defines the mapping between a Microsoft Entra ID (Azure AD) commercial license plan, directory role, or application identifier and specific Business Central objects or permission sets. Entitlements are primarily authored by AppSource ISVs and specialized enterprise developers to enforce tier-based licensing models.

entitlement 50100 "Loyalty App Essential Plan"
{
    Type = Plan;
    Id = '9638a72e-333e-4cf3-ad1a-cd43a75877f0'; // Dynamics 365 Business Central Essential Service Plan GUID

    ObjectEntitlements =
        tabledata "Loyalty Member" = RIMD,
        table "Loyalty Member" = X,
        page "Loyalty Member Card" = X,
        codeunit "Loyalty Processing Engine" = X;

    IncludedPermissionSets = "Loyalty Manager";
}

Key Properties of Entitlement Objects

4. Comprehensive Security Evaluation Hierarchy

When an AL procedure attempts to read or modify a database record at runtime, the Business Central Navision Server Tier (NST) executes a deterministic evaluation pipeline:

1. Check Base Entitlement Ceiling:
   Is the requested operation permitted by the user's Entra ID License Plan (Essential, Team Member)?
   ├── YES ──> Proceed to Step 2.
   └── NO  ──> Is the executing procedure decorated with [InherentEntitlements]?
               ├── YES ──> Elevate Entitlement Ceiling and Proceed to Step 2.
               └── NO  ──> THROW LICENSE ENTITLEMENT ERROR (Blocked by License).

2. Check User Assigned Permissions:
   Does the user have assigned Permission Sets (or Security Groups) granting direct or indirect rights?
   ├── DIRECT (RIMD)   ──> OPERATION PERMITTED.
   ├── INDIRECT (rimd) ──> Does the executing object declare Permissions in its header?
   │                       ├── YES ──> OPERATION PERMITTED (Elevated by Object).
   │                       └── NO  ──> THROW PERMISSION ERROR (Requires Object Elevation).
   └── NONE            ──> Is the executing procedure decorated with [InherentPermissions]?
                           ├── YES ──> OPERATION PERMITTED (Elevated by InherentPermissions).
                           └── NO  ──> THROW PERMISSION ERROR (Access Denied).