How to control permissions for specific operations

In this video, I look at how to control access to specific functions within a single object. Check out the video:

https://youtu.be/hiobKJiUiVQ

In this video, Erik demonstrates a cleaner approach to controlling access for specific operations in Business Central. Instead of the common pattern of adding Boolean fields to setup tables (like User Setup), he shows how to leverage the existing permission set infrastructure to create operation-specific permission checks — resulting in a more maintainable and integrated security model.

The Problem: Boolean Fields in Setup Tables

A very common customization pattern in Business Central involves controlling who can perform specific operations by adding Boolean fields to tables like User Setup or Warehouse Employees. For example, a developer might add a field called “Is Allowed to Post” or “Can Run Special Process” and then check that flag in code before allowing the operation.

Microsoft themselves use this pattern — the User Setup table already contains fields like “Time Sheet Admin” and various posting permission flags. But as Erik points out, this approach has significant drawbacks:

  • Setup tables accumulate more and more Boolean columns over time, becoming unwieldy
  • Permission checks are scattered across multiple tables (User Setup, Warehouse Employees, etc.)
  • These custom flags live outside the standard permission system, making them harder to manage
  • New user onboarding requires configuring settings in multiple places

The Better Approach: Empty Permission Sets

Erik’s proposed solution is elegant in its simplicity: create a permission set with no objects associated with it. The permission set exists solely as a flag to indicate that a user is authorized to perform a specific operation. Then, in your AL code, you simply check whether the current user has that permission set assigned.

This approach integrates directly with Business Central’s existing security infrastructure, meaning you get all the benefits of:

  • User group assignments (and future Azure AD group integration)
  • Default permission configuration for new users based on license type
  • Centralized permission management through a single, familiar interface
  • Standard permission set assignment workflows

Implementation Walkthrough

Erik demonstrates this by creating a page extension on the Customer List that adds an action only certain users should be able to execute.

Step 1: Create the Action

First, add an action to the Customer List page that represents the restricted operation:

pageextension 50100 CustomerListExt extends "Customer List"
{
    actions
    {
        addlast(processing)
        {
            action(OnlyForTheFew)
            {
                ApplicationArea = All;
                Caption = 'Only for the Few';

                trigger OnAction()
                var
                    AC: Record "Access Control";
                begin
                    AC.SetRange("User Security ID", UserSecurityId());
                    AC.SetFilter("Role ID", 'ONLY THE FEW');

                    if AC.IsEmpty() then
                        Error('You are not one of the few!')
                    else
                        Message('Hello! Here is a great action.');
                end;
            }
        }
    }
}

Step 2: Check the Permission Set in Code

The key technique is using the Access Control table, which holds the permission set assignments for users. The code filters this table by the current user’s Security ID and looks for a specific Role ID (permission set name). If no record is found, the user doesn’t have the permission set and is denied access.

Here’s the core logic broken down:

  1. Declare a variable of type Record "Access Control"
  2. Set a range on "User Security ID" using the built-in UserSecurityId() function
  3. Set a filter on "Role ID" for your custom permission set name
  4. Check if the filtered record set is empty — if it is, the user doesn’t have the permission

Step 3: Create the Permission Set

In Business Central, navigate to Permission Sets and create a new one called “ONLY THE FEW”. That’s it — you don’t need to add any object permissions to it. The permission set exists purely as an authorization token.

Step 4: Assign It to Users

Assign the permission set to the users who should have access to the restricted operation, just as you would any other permission set. When Erik tested this without the permission set assigned, he received the error message. After assigning “ONLY THE FEW” to his user, the action worked successfully.

Production Considerations

Erik notes that in a production scenario, you’d want to wrap this check in a reusable codeunit — something like a “Check My Permissions” utility — so you don’t repeat the Access Control table lookup logic everywhere. You could create a clean function interface that accepts a permission set name and returns a Boolean.

For example:

codeunit 50100 "Permission Helper"
{
    procedure HasPermissionSet(RoleID: Code[20]): Boolean
    var
        AC: Record "Access Control";
    begin
        AC.SetRange("User Security ID", UserSecurityId());
        AC.SetFilter("Role ID", RoleID);
        exit(not AC.IsEmpty());
    end;
}

Converting Existing Permission Sets to AL

If you’re working with an existing on-premises environment and need to convert legacy permission sets to the AL permissionset object format, the provided PowerShell module Convert-PermissionSets can automate that process. It reads permission sets from a SQL database, resolves object names using downloaded symbols, and generates .permissionset.al files.

The core function is invoked like this:

Convert-PermissionSets -DatabaseServer localhost -DatabaseName W1 -Destination ".\NewPermissionSets"

The module handles the full pipeline:

  • Symbol download and processing — Downloads app symbols from the Published Application table and decompresses them to resolve object IDs to names
  • Permission reading — Queries both the Permission and Tenant Permission tables to capture all permission sets
  • Permission mask conversion — Converts numeric permission values (0, 1, 2) to the symbolic AL format (R, I, M, D, X for direct permissions; r, i, m, d, x for indirect)
  • File generation — Writes properly formatted .permissionset.al files with captions, assignability settings, and sorted permission lines

The generated AL permission set files include metadata like Access = Public, Assignable = true, and the original caption, making them ready to include in an AL extension project.

Conclusion

Using empty permission sets as operation-level authorization flags is a clean, maintainable pattern that integrates naturally with Business Central’s existing security model. Rather than scattering Boolean fields across multiple setup tables, you centralize all access control in one place — the permission system — where administrators already expect to manage it. This approach scales better, is easier to audit, and benefits from all the infrastructure Microsoft continues to build around permissions, including upcoming Azure AD group integration.

Picture of hougaard

hougaard