Permission Set Extensions in AL are used to add permissions to existing permission sets without modifying them. They are a critical part of Business Central’s extensibility model, especially when extending standard permission sets provided by Microsoft.
This page explains what permission set extensions are, why they exist, and how they should be used correctly in real implementations. The focus is on understanding permission set extensions as a security extension mechanism, not just another AL object.
Why Permission Set Extensions Exist
Standard permission sets are delivered and maintained by Microsoft. These sets often cover most business scenarios, but they do not include permissions for custom tables, pages, reports, or codeunits created in extensions.
Modifying standard permission sets directly would:
• Be overwritten during upgrades
• Break compatibility with new versions
• Create maintenance and support issues
Permission set extensions exist to solve this problem by allowing safe, additive security customization.
What Is a Permission Set Extension?
A permission set extension is an AL object that extends an existing permission set by adding new permissions. It does not replace the original permission set and cannot remove permissions from it.
A permission set extension:
• Adds permissions only
• Targets an existing permission set
• Is applied automatically at runtime
• Preserves upgrade safety
A permission set extension cannot:
• Remove permissions
• Deny access
• Override base permission logic
This additive behavior is intentional and fundamental.
How Permission Set Extensions Work
When a permission set extension is installed:
• The base permission set remains unchanged
• Additional permissions from the extension are merged
• Users assigned to the base set automatically gain the new permissions
This ensures:
• No reconfiguration after upgrades
• Predictable permission behavior
• Clean separation between standard and custom security
Permission set extensions are defined using the permissionsetextension object.
Example: Defining a Permission Set Extension
permissionsetextension 50210 "Customer Feedback Permissions Ext"
extends "D365 BASIC"
{
Permissions =
tabledata "Customer Feedback" = RIMD,
page "Customer Feedback List" = X,
page "Customer Feedback Card" = X,
codeunit "Customer Feedback Management" = X;
}
This extension:
• Extends a standard permission set
• Grants access to custom objects
• Requires no modification to the base set
When to Use Permission Set Extensions
Permission set extensions should be used when:
• You create custom objects
• Standard permission sets must allow access to them
• Upgrade safety is required
• You want automatic permission inheritance
They are especially important in ISV solutions and long-lived extensions.
Permission Set Extensions vs New Permission Sets
Permission set extensions are best when:
• You want to enhance an existing role
• Users already rely on standard permission sets
• You want minimal admin effort
Creating a new permission set is better when:
• A completely new role is required
• Security requirements differ significantly
• You want strict isolation
Choosing correctly simplifies security management.
Common Beginner Mistakes With Permission Set Extensions
Developers often:
• Forget to include execute permissions
• Extend the wrong base permission set
• Assume permissions can be removed
• Rely on SUPER during testing
These mistakes lead to runtime errors or security gaps.
Best Practices for Permission Set Extensions
Well-designed permission set extensions:
• Extend the lowest appropriate base set
• Grant minimum required permissions
• Include all required object permissions
• Are tested with restricted users
Security should always be intentional.
Summary
Permission set extensions in AL provide a safe, upgrade-proof way to grant access to custom functionality in Business Central. They allow developers to integrate custom objects into existing security models without modifying standard permission sets.
A well-designed permission set extension:
• Preserves standard security
• Adds only what is necessary
• Survives upgrades cleanly
• Reduces administrative effort
Understanding permission set extensions completes the extensible security layer of AL development.
Practical check: Add a custom inquiry page to an existing read role
An extension adds a read-only shipment inquiry page backed by an extension table. Users already receive an appropriate inquiry role from another app.
Steps and evidence to inspect
- Create the custom table/page with the smallest required indirect/direct permissions.
- Extend the known permission set and add only read/execute access needed by the inquiry.
- Assign the base role to a clean test user, verify the inquiry works, and prove edit/delete remains blocked.
Expected result
The existing role gains access to the new inquiry while ownership and future changes to the base permission set remain with its publisher.
If the result is different
If compilation cannot find the set, inspect app dependency, scope, version, and set name. If the user still fails, distinguish page execute permission from table-data read permission and licence entitlement.
Version and implementation boundary
Permission set extensions only add; they cannot subtract unsafe permissions from the base set. Review the combined effective permissions and dependency lifecycle.
Authoritative reference: Microsoft Learn — Permission set extension object. The scenario and interpretation above are original to ScrutnLearn.