Permission sets in AL define what a user is allowed to read, insert, modify, delete, or execute inside Business Central. They are the foundation of authorization and security, ensuring that users can perform only the actions required for their role—nothing more, nothing less.
This page explains what permission sets are, why they exist, how they are defined in AL, and how they are extended safely using Permission Set Extensions. The goal is to help learners understand permissions as a security design responsibility, not just a technical checkbox.
What Is a Permission Set in Business Central?
A permission set is a collection of object-level permissions that control access to tables, pages, reports, codeunits, queries, and XML ports. Permission sets do not grant access to data directly; instead, they define which operations are allowed on which objects.
A permission set controls:
• Read access to data
• Ability to create or modify records
• Ability to delete records
• Ability to execute objects
Permission sets do not:
• Control UI layout
• Replace business logic validations
• Automatically restrict all access (users may have multiple sets)
They are the authorization layer of Business Central.
Why Permission Sets Exist
Business Central is used by many roles:
• Accountants
• Sales users
• Warehouse users
• Managers
• Developers
• Integrations and service accounts
Each role requires different levels of access. Permission sets exist to:
• Enforce separation of duties
• Protect sensitive data
• Reduce accidental data corruption
• Support audits and compliance
Security in ERP is not optional; it is a core requirement.
How Permission Sets Work Conceptually
Users are assigned one or more permission sets. The system evaluates all assigned permission sets and calculates the effective permissions. If any assigned permission set grants access, the user can perform the action.
This means:
• Permission sets are additive
• Deny rules do not exist
• Security must be designed carefully
Understanding this behavior is critical for correct security design.
Permission sets can be defined in AL using the permissionset object.
Example: Permission Set
permissionset 50200 "Customer Feedback User"
{
Assignable = true;
Permissions =
tabledata "Customer Feedback" = RIMD,
page "Customer Feedback List" = X,
page "Customer Feedback Card" = X;
}
This permission set:
• Allows full access to the Customer Feedback table
• Allows execution of related pages
• Can be assigned to users
Understanding Permission Symbols
The permission letters represent allowed actions:
• R → Read
• I → Insert
• M → Modify
• D → Delete
• X → Execute
These symbols apply depending on object type.
Table vs TableData Permissions
It is important to distinguish between table objects and table data.
• tabledata → Controls access to records (most common)
• table → Controls access to table definition (rarely used)
In almost all business scenarios, tabledata permissions are used.
Granting Execute Permissions
Objects like pages, reports, and codeunits require execute (X) permission.
Permissions =codeunit "Customer Feedback Management" = X;
Without execute permission, the object cannot run—even if the user can see it in the UI.
Permission Set Extensions
Permission set extensions allow you to extend an existing permission set without modifying it. This is critical for:
• Extending standard permission sets
• Preserving upgrade safety
• Adding access for custom objects
Example: Permission Set Extension
permissionsetextension 50201 "Customer Feedback User Ext"
extends "Customer Feedback User"
{
Permissions =
report "Customer Feedback Processor" = X;
}
This extension:
• Adds permissions to an existing set
• Does not replace the base permission set
• Survives upgrades safely
Permission Sets and Custom Objects
Every custom object you create should be:
• Reviewed for required permissions
• Included in appropriate permission sets
• Tested with restricted users
Security should be considered during development, not after deployment.
Common Beginner Mistakes With Permission Sets
Developers often:
• Grant full permissions unnecessarily
• Forget to add execute permissions
• Rely on SUPER users for testing
• Ignore permission testing entirely
These mistakes can lead to security gaps or runtime errors.
Summary
Permission sets in AL define who can do what in Business Central. They are essential for protecting data, enforcing roles, and ensuring system stability.
A well-designed permission strategy:
• Grants minimum required access
• Uses permission set extensions
• Avoids over-permissioning
• Supports audit and compliance
Understanding permission sets completes the security foundation of AL development.
Practical check: Build a read-and-run inquiry role
A support user may view a custom shipment inquiry and run its summary report but must not insert, modify, or delete shipment data.
Steps and evidence to inspect
- Grant page/report execute plus the minimum table-data read permissions.
- Assign only this role and unavoidable platform permissions to a dedicated test user.
- Run the inquiry/report, then attempt an edit and record the denied result as part of the test.
Expected result
The user completes the approved inquiry and cannot mutate the protected data. The result proves both allowed and denied paths.
If the result is different
SUPER masks missing permissions, so never validate with the developer account alone. Use permission recording or telemetry to identify the exact object, then decide whether the task truly requires it.
Version and implementation boundary
Licences, entitlements, security filters, indirect permissions, and other assigned sets affect effective access. A code review of one permission object is not the full security test.
Authoritative reference: Microsoft Learn — Permission set object. The scenario and interpretation above are original to ScrutnLearn.