A source of eternal confusion is the difference between roles and permissions in Business Central. In this video, I try to untangle it. Check it out:
In this video, Erik explains a concept that might seem obvious but is frequently misunderstood in Business Central: roles (profiles) and permissions are two completely separate systems. He walks through how each system works, how they interact, and why understanding the distinction is critical for properly managing user access and experience.
Roles (Profiles) vs. Permissions: Two Separate Systems
Business Central has two completely separate systems that govern the user experience:
- Roles (also known as Profiles) — Control what the user sees when they log in
- Permissions — Control what the user can access and do in the system
These two systems are entirely independent of each other, and confusing one for the other is a common mistake.
What Do Roles Actually Do?
The sole purpose of a role is to present the most relevant information to a user when they log in. A role connects you to a Role Center page — that’s the home page you see when you open Business Central — and it defines what content appears in the Role Explorer.
For example, if Erik sets his role to “Shipping and Receiving – Warehouse Management,” he sees warehouse-related activities on his home page. If he switches to “Project Manager,” he instead sees jobs, job tasks, customers, activities, work in progress, approvals, and timesheets — all project-related content.
However, here’s the key insight: even as a Project Manager, Erik can still navigate to the Chart of Accounts, General Ledger Setup, or run “Close Income Statement” — because those actions are governed by permissions, not roles. The role only determines what’s presented upfront; it doesn’t restrict where you can go.
How Permissions Work
Permissions are configured on the User card, through permission sets and user groups. This is where you define whether a user should have access to the chart of accounts, employees, jobs, or any other area of the system.
Business Central provides an Effective Permissions view that shows you exactly what access a user has and where that access comes from. Erik demonstrates this by looking at the G/L Account table:
- Entitlement (License) — The bottom layer. This is what Microsoft grants based on your license type. It defines the maximum possible access.
- Permission Sets — Various permission sets stack on top, each contributing to or restricting access.
- Effective Result — The top row shows the net result of all permission layers combined.
Direct vs. Indirect Permissions
Erik highlights an important nuance with the G/L Entry table. Even though the “SUPER” permission set grants full access to everything, the effective permissions for G/L Entry show only indirect insert, modify, and delete access. What does “indirect” mean? It means that only code that has been explicitly allowed can write to the G/L Entry table — a user cannot directly modify entries through the UI. This is by design, to fulfill the requirements of local accounting laws and ensure data integrity.
So even SUPER doesn’t truly mean “access to everything” — the entitlement layer can reduce what SUPER grants.
How Roles and Permissions Interact
Here’s how the two systems connect: if you don’t have permissions to access certain data, that data won’t show up in your role center or in the role explorer. The role explorer respects permissions — it won’t display pages or data you’re not entitled to see.
This means that if you want to customize what a user sees in their Role Explorer, you need to manage it through permissions, not roles. Roles control the layout and presentation; permissions control actual access.
Bonus: A Better User Management Page
Along with this video, Erik shares source code for a custom “User Management” page that provides a consolidated overview of user configuration across multiple areas of Business Central. This is a handy tool for administrators who need to quickly see which users have been set up in various subsystems.
page 50100 "User Management"
{
ApplicationArea = All;
Caption = 'User Management';
PageType = List;
SourceTable = User;
UsageCategory = Administration;
Editable = false;
layout
{
area(Content)
{
repeater(General)
{
field("User Name"; Rec."User Name")
{
Width = 5;
}
field("Full Name"; Rec."Full Name")
{
Width = 10;
}
field(State; Rec.State)
{
Width = 5;
}
field(SettingsCtl; Settings)
{
Editable = false;
Caption = 'Settings';
Width = 1;
trigger OnDrillDown()
var
UserSettings: Record "User Personalization";
begin
UserSettings.Setrange("User SID", Rec."User Security ID");
Page.RunModal(Page::"User Personalization", UserSettings);
CurrPage.Update();
end;
}
field(AccountingSetupCtl; AccountingSetup)
{
Editable = false;
Caption = 'Accounting';
Width = 1;
trigger OnDrillDown()
var
U: Record "User Setup";
begin
U.Setrange("User ID", Rec."User Name");
Page.RunModal(Page::"User Setup", U);
CurrPage.Update();
end;
}
field(ApprovalCtl; Approval)
{
Editable = false;
Caption = 'Approval';
Width = 1;
trigger OnDrillDown()
var
U: Record "User Setup";
begin
U.Setrange("User ID", Rec."User Name");
Page.RunModal(Page::"Approval User Setup", U);
CurrPage.Update();
end;
}
field(WarehouseCtl; Warehouse)
{
Editable = false;
Caption = 'Warehouse';
Width = 1;
trigger OnDrillDown()
var
U: Record "Warehouse Employee";
begin
U.Setrange("User ID", Rec."User Name");
Page.RunModal(Page::"Warehouse Employees", U);
CurrPage.Update();
end;
}
field(FACtl; FA)
{
Editable = false;
Caption = 'Fixed Assets';
Width = 1;
trigger OnDrillDown()
var
U: Record "FA Journal Setup";
begin
U.Setrange("User ID", Rec."User Name");
Page.RunModal(Page::"FA Journal Setup", U);
CurrPage.Update();
end;
}
field(ResourceCtl; Resource)
{
Editable = false;
Caption = 'Resource';
Width = 1;
trigger OnDrillDown()
var
U: Record Resource;
begin
U.Setrange("No.", Rec."User Name");
Page.RunModal(Page::"Resource Card", U);
CurrPage.Update();
end;
}
field(EmployeeCtl; Employee)
{
Editable = false;
Caption = 'Employee';
Width = 1;
trigger OnDrillDown()
var
U: Record Employee;
begin
U.Setrange("No.", Rec."User Name");
Page.RunModal(Page::"Employee Card", U);
CurrPage.Update();
end;
}
}
}
}
trigger OnAfterGetRecord()
begin
UpdateGlobals();
end;
trigger OnAfterGetCurrRecord()
begin
UpdateGlobals();
end;
local procedure UpdateGlobals()
var
UserSettings: Record "User Personalization";
UserSetup: Record "User Setup";
WarehouseEmployee: Record "Warehouse Employee";
FASetup: Record "FA Journal Setup";
ResourceRec: Record Resource;
EmployeeRec: Record Employee;
begin
UserSettings.Setrange("User SID", Rec."User Security ID");
if UserSettings.IsEmpty() then
Settings := '❌'
else
Settings := '✅';
UserSetup.Setrange("User ID", Rec."User Name");
If UserSetup.IsEmpty() then
AccountingSetup := '❌'
else
AccountingSetup := '✅';
Approval := '❌';
If UserSetup.FindFirst() then
if (UserSetup."Sales Amount Approval Limit" <> 0) or
(UserSetup."Purchase Amount Approval Limit" <> 0) or
(UserSetup."Unlimited Sales Approval") or
(UserSetup."Unlimited Purchase Approval") or
(UserSetup."Unlimited Request Approval") or
(UserSetup."Unlimited Request Approval") or
(UserSetup."Approver ID" <> '') then
Approval := '✅';
WarehouseEmployee.Setrange("User ID", Rec."User Name");
if WarehouseEmployee.IsEmpty() then
Warehouse := '❌'
else
Warehouse := '✅';
FASetup.Setrange("User ID", Rec."User Name");
if FASetup.IsEmpty() then
FA := '❌'
else
FA := '✅';
ResourceRec.Setrange("No.", Rec."User Name");
if ResourceRec.IsEmpty() then
Resource := '❌'
else
Resource := '✅';
EmployeeRec.Setrange("No.", Rec."User Name");
if EmployeeRec.IsEmpty() then
Employee := '❌'
else
Employee := '✅';
end;
var
Settings: Text;
AccountingSetup: Text;
Approval: Text;
Warehouse: Text;
FA: Text;
Resource: Text;
Employee: Text;
}This page displays a list of all users with ✅ and ❌ indicators showing at a glance whether each user has been configured in:
- User Personalization (Settings)
- User Setup (Accounting)
- Approval User Setup (Approval — checks for approval limits, unlimited approval flags, or an approver ID)
- Warehouse Employees
- FA Journal Setup (Fixed Assets)
- Resource records
- Employee records
Each indicator is drillable — clicking on it opens the corresponding setup page filtered to that user, making it easy to configure or review settings without hunting through multiple pages.
Summary
The key takeaway is straightforward but important: Roles are not permissions, and permissions are not roles. Roles (profiles) control the presentation layer — what a user sees on their home page and in the Role Explorer. Permissions control actual data access — what a user can read, insert, modify, or delete. The two systems are independent, though they do interact: the Role Explorer will hide content that a user doesn’t have permission to access. If you want to restrict what a user can do, manage their permissions. If you want to customize what they see first when they log in, manage their role.
