Business Central Permissions: Groups, Levels & Best Practice

Learn how Business Central permission sets, Security Groups, and permission levels work together. Plus best practices, common pitfalls, and a post-update permissions triage checklist.

If you’ve ever fixed a permissions issue by handing out SUPER, you didn’t fix it. You just put the business in a superhero costume and called it governance. Let’s do it properly.

The three building blocks that decide what a user can do

Business Central permissions are built from:

1. Permission sets – what access is granted
2. Security Groups (Entra ID) – how you assign permission sets at scale
3. Permission levels – what type of access within objects (read/create/edit/delete/execute)

Microsoft’s core model is permission sets + assignment (users and groups), and you can review the resulting access using the Effective Permissions page.

1) Permission sets: the “what” of access

A permission set is a named bundle of permissions to objects (tables, pages, reports, codeunits, etc.). You assign one or more permission sets to grant access.

Permission levels (what “levels” actually means)

In permission sets you typically see:

• R = Read

• I = Insert (create)

• M = Modify (edit)

• D = Delete

• X = Execute (run objects like reports/codeunits)

Reality check: users often get permission errors during posting because posting calls other objects behind the scenes (codeunits, tabledata, etc.). It’s not “they can open the page, therefore they can do the process”.

Company scoping (the silent access leak)

When you assign permission sets (directly or via Security Groups), you can scope them to a specific company or all companies (blank Company). Microsoft explicitly calls this out.

If you run multi-company and you’re sloppy here, you’re basically leaving keys under the doormat.

2) Security Groups (Entra ID): the “who gets what” mechanism

Security Groups connect Business Central access to Microsoft Entra ID groups. You assign permission sets to the group in Business Central, manage membership in Entra, and users inherit those permissions.

Why we recommend Security Groups

Because it’s the most maintainable and auditable approach:

• Joiners/movers/leavers handled centrally

• Role-based access management (RBAC) becomes real

• Fewer “random direct assignments” that build up over time

Legacy User Groups still exist, but the direction of travel is clear: standardise on Security Groups where you can.

3) How they work together (the only mental model that matters)

A user’s actual access is the result of:

• Permission sets assigned directly

• Permission sets inherited via Security Groups

• Company scoping on assignments

• Any security filters (record-level restrictions), where used

Business Central’s Effective Permissions view helps you see not only what access exists, but also the source (for example: inherited via security group) and relevant security filter information.

Best practices 

1) Design roles, not users

Build a small number of roles that match how the business works (AP Clerk, Finance Manager, Warehouse Picker, Sales Ops). Then assign via Security Groups.

2) Keep permission sets composable

Instead of one monster “Finance” set, use building blocks, e.g.:

• FINANCE-CORE

• FINANCE-AP

• FINANCE-AR

• FINANCE-APPROVALS

• EXT-CONTINIA / EXT-… (per app/extension)

This makes troubleshooting faster and reduces collateral damage when something changes.

3) Keep SUPER on a strict diet

Use SUPER only for a tiny admin group and (optionally) a break-glass account with a process. Do not let it become your “implementation seasoning”.

4) Prefer Security Groups; avoid direct user assignments

Direct assignments should be exceptions, not the norm — and should be time-boxed with a removal date.

5) Extensions can quietly widen access

Permission changes can come from apps/extensions, and permission sets can be changed by extensions. If you don’t review access after installing/updating apps, you’re guessing.

What to watch out for (common traps)

Trap 1: Multi-company access by accident

Leaving Company blank on group assignment lines can apply permissions across all companies. Microsoft calls this out explicitly.

Trap 2: “Read-only is harmless”

Read access can still expose margins, pricing, vendor bank details, and other sensitive data. Security isn’t only about posting rights.

Trap 3: Permissions drift

Temporary access gets added. Nobody removes it. Six months later, you’ve got a Frankenstein security model.

Trap 4: Copies of system permission sets become upgrade landmines

This leads into the next topic…

Can Microsoft updates override permissions?

They can change what’s required — and they can update system sets — but they won’t magically maintain your custom copies.

Here’s the straight answer:

• In Business Central online, Microsoft ships system permission sets as AL objects in Microsoft apps/extensions; you can’t customise system permission sets in online. You can only copy them and adjust your own versions.

• Microsoft updates can introduce new permissions requirements or new dependencies. That means users can start seeing permission errors after an update even if you didn’t change anything.

• If you use custom copied permission sets, Microsoft won’t automatically adjust your copies when system sets evolve. That’s why copied sets are a classic cause of post-update permission errors.

• You can monitor and audit permission changes and assignments using telemetry (including changes caused by apps/extensions).

So yes: updates can absolutely change outcomes. Not by “overriding your setup”, but by changing the moving parts around it.

Role matrix example

Design rules you can use:

• One Entra group per role, split further by company if needed (e.g., BC-FIN-AP-COA, BC-FIN-AP-COB)

• Keep extension permissions separate (so app upgrades don’t blindside you)

• Avoid direct assignment unless temporary and documented

Security Groups + company-scoped assignment is standard and explicitly supported by Microsoft.

Post-update permissions triage checklist (fast, repeatable, no drama)

When users report “I suddenly can’t post / can’t release / can’t run X after the update”, do this:

1) Confirm it’s a permissions error (not data/setup)

• Get the exact error message and user ID

• Confirm whether it happens for all users in the same role or only one user

  • If it’s only one user: suspect direct assignments or group membership mismatch

2) Check Effective Permissions for the user

• Open Effective Permissions and verify the permission source (direct vs group) and whether security filters are involved.

3) Identify the failing object and missing permission type

From the error message (or telemetry), capture:

• Object type (TableData / Codeunit / Report / Page)

• Object ID/name

• Missing operation (Read/Insert/Modify/Delete/Execute)

4) Check whether the issue is update-related

Common signs:

• Started immediately after the Microsoft update window

• Affected multiple users with the same role

• Involves objects related to new/changed features or updated apps

Telemetry can help you analyse permission errors in online environments via Application Insights.

5) Decide the least risky fix path

Use this order:

1. Add a small, specific permission set (or update a role-specific set) to grant only what’s missing
2. If you’re using a copied system set, compare against the updated system set and update your copy accordingly (this is where people get bitten)
3. If it’s caused by an extension, review whether the extension introduced permission changes and whether your role model needs an “EXT-…” set adjustment
4. Do not solve it with SUPER unless it’s break-glass while you implement (1)-(3)

6) Validate in Sandbox first (when possible)

• Reproduce the process in Sandbox with the same role assignments

• Confirm the fix doesn’t widen access unexpectedly (especially cross-company)

7) Document the change in your Role Matrix

• What changed, why, who approved, and which role(s) were affected

• Set a review date (so “temporary” doesn’t become permanent)

8) Set monitoring for future drift

Permission changes telemetry can track:

• assignments to users/groups

• links between user-defined and system sets

• changes caused by apps/extensions

Final Words

If your permissions model is built on copied system sets with random tweaks and loads of direct user assignments, you’re not managing security — you’re managing surprise.

Build roles. Assign via Entra Security Groups. Keep permission sets modular. Treat updates as a normal operational event, not a once-a-year panic.

Next Step

Get in touch if you want Business Central to work better for your business.