Permissions and security in Business Central

By Emil Björk · Microsoft business apps consultant, Gothenburg

How Business Central security really works — permission sets, user groups, security filters, and the data residency boundaries you should know about.

Reviewed August 20262 min read · 418 wordsPublished Updated
On this page (9)

Business Central's security model is built around permission sets that grant read, insert, modify, delete, and execute (RIMDX) rights on individual database objects — tables, pages, codeunits, reports, queries. Users get effective permissions by being assigned one or more permission sets, optionally bundled into user groups for easier administration.

Permission sets

Microsoft ships a long list of built-in permission sets — SUPER, BASIC, SETUP, sales-related, finance-related, manufacturing-related — and extensions add their own. Built-in sets are read-only; to customise, you copy one and edit the copy, or write a new permission set in AL. Permission sets are versioned and can be assigned via plans automatically based on the user's licence type (Essentials, Premium, Team Member), preventing over-privileging.

User groups

A user group is a named collection of permission sets, assignable in one step. Most customers organise security around job roles — "AP Clerk", "Sales Manager", "Warehouse Operator" — each as a user group bundling the right sets.

Security filters

A permission set can include security filters — row-level filters that constrain a user's access to a subset of a table (e.g. only one location's items, or only one dimension value's GL entries). Filters are powerful but harder to test; use sparingly.

Direct vs indirect permissions

Reading a customer record via the customer card needs direct read on Customer. Posting a sales invoice writes to many tables via indirect permission, granted through codeunit execution rights rather than direct table rights. Indirect is the modern pattern; using direct write rights on transactional tables is usually a misconfiguration.

Effective permissions tool

From any user card, the Effective Permissions page shows exactly what RIMDX rights the user has on any object, and which permission set granted them. Use it to debug permission errors.

Identity and SSO

All BC SaaS users sign in with Microsoft Entra ID. Multi-factor authentication, conditional access, named locations, and lifecycle automation are configured in Entra, not in BC. Service-to-service API calls authenticate via Entra app registrations with application permissions.

Data residency

BC SaaS data lives in the Microsoft data centre region selected at tenant creation and never leaves it. Moving between regions requires a tenant migration.

Audit

Built-in change-log for sensitive tables, plus integration with Microsoft Purview for tenant-wide audit retention.

Where to go next

Audit on top of permissions is the change log and audit trail; identity controls live in Entra, covered in conditional access. The permission errors users and integrations hit are decoded in AL runtime errors and Business Central API errors. Environments carry their own access model — see Business Central environments.

Frequently asked questions

What is a permission set in Business Central?

A named set of read, insert, modify, delete, and execute rights on tables, pages, codeunits, reports, and queries. Built-in sets are read-only; customise by copying one or writing a new set in AL, and bundle sets into user groups per job role.

What is the difference between direct and indirect permissions?

Direct permission lets a user read or write a table from its page; indirect permission lets a codeunit write to tables on the user's behalf during posting. Indirect is the modern pattern — direct write rights on transactional tables are usually a misconfiguration.

How do I debug a permission error?

Open the Effective Permissions page from the user card. It shows exactly which rights the user has on any object and which permission set granted them.

Where are MFA and conditional access configured?

In Microsoft Entra ID, not Business Central. All SaaS users sign in through Entra, and service-to-service API calls use app registrations with application permissions.

Further reading

Related guides

Browse every guide in Business Central or just Admin & ops.

Was this helpful?

Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.