Permissions and security in Business Central

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.