If your organization has been running dynamics 365 business central services for more than a year or two, there is a reasonable chance your permissions model has drifted from where it started. A new hire gets added in a hurry and inherits the closest existing profile. A department restructure leaves behind access rights nobody thinks to remove. A go-live shortcut assigning a broad default permission set because time was short  never gets revisited. Slowly, quietly, the access structure that was meant to control your system starts to resemble a layer cake of historical decisions nobody fully remembers making.

The reassuring part: you almost certainly do not need to start over. Business Central already contains everything required to build a clean, auditable, role-aligned permission model. The work is about applying it with clarity — not about adding complexity on top of what you already have.

This guide walks through the most common permission mistakes, explains the architecture you should be working with, and gives you a practical path to fixing what is broken.

Why This Is a Business Problem, Not Just an IT One

Business Central, as part of the broader Dynamics 365 ERP ecosystem, holds some of your most sensitive operational data — general ledger entries, vendor payment instructions, customer credit terms, payroll figures, inventory valuations. Misconfigured access in this environment is not an abstract risk. It is a direct exposure.

Regulators and auditors increasingly expect organization’s to demonstrate that financial system access is controlled, documented, and reviewed. Questions like “who can post a journal entry without approval?” or “which users can modify vendor bank details?” should be answerable in minutes. In many Business Central environments we encounter, they take days — if they can be answered at all.

The permission model is also the primary mechanism for enforcing segregation of duties: the principle that no single person should be able to initiate, approve, and complete a sensitive financial transaction without a second set of eyes. Without a deliberate design, that separation often exists in theory but not in practice.

The Four Layers You Need to Understand

Business Central’s security architecture works in layers. Most permission problems stem from organisations only engaging with one or two of them.

Permission Sets

The base layer. A permission set defines precisely what a user can do with a specific system object: read a record, insert a new entry, modify existing data, delete it, or execute a process. Microsoft ships a library of pre-built sets aligned to common functions — accounts payable, warehouse management, project accounting, and so on. These defaults are deliberately broad, covering the maximum range of tasks someone in that function might ever require. Assigning them wholesale almost always grants more access than any individual actually needs.

Security Groups

Rather than assigning permission sets to individual users one by one, Business Central supports security groups collections of users with shared responsibilities, managed through Microsoft Entra ID. A new accounts payable clerk gets added to the AP group. When their role changes, they move to a different group. When they leave, they are removed. Access follows the person’s current function, not their employment history.

Security Filters

Permission sets control what a user can do. Security filters control which records they can do it with. A finance manager in one legal entity can have full posting rights while a filter prevents them from touching transactions in a different entity. Action rights and data scope are managed independently, which is the only way to achieve genuine data separation in a multi-entity environment.

Licence Entitlements

The ceiling beneath everything else. A user’s Microsoft licence type places hard limits on what they can access regardless of which permission sets are assigned. Assigning posting rights to a Team Member licence holder does nothing the licence prevents it. Understanding this ceiling before designing your permission structure saves the frustration of configuring access that will be silently blocked at the licence layer.

The Three Most Common Mistakes

Assigning Default Sets Without Reviewing Them

The standard permission sets are starting points, not finished solutions. Take the D365 PURCH DOC EDIT set as an example: it grants access to more than ninety objects, a number of which carry Modify rights on master data tables that most purchasing clerks should never need to change. Assigning it to your entire purchasing team means twenty-plus people can edit payment terms, even though perhaps two of them ever would. The access is there. It represents both a compliance gap and a fraud vector.

The fix is purpose-built custom sets. Instead of one large purchasing set, create a hierarchy — a view-only set for lookup access, an edit set for day-to-day transaction work, an admin set for those with genuine master data responsibilities. Each user gets the set that matches their actual job, nothing more.

Building Access Around Org Chart Departments Instead of Job Tasks

Departments and job tasks are not the same thing. Two people in the same department can have meaningfully different system requirements. A junior AP clerk and a senior AP manager both sit in finance but the clerk should be entering invoices and matching receipts, while the manager needs to approve payments, reconcile accounts, and manage vendor master data. One department, two distinct permission profiles.

Start your permission design with a task matrix, not an org chart. Map each distinct role to the specific things that role needs to do in the system. That mapping becomes the blueprint for your permission sets.

Never Removing Access When Roles Change

Privilege accumulation the gradual gathering of access rights as people move through roles without having previous permissions removed — is one of the most common findings in access control audits. The person who spent six months covering for the finance manager still has finance manager access two years later. Multiply that across a growing organisation and the effective permissions landscape bears very little resemblance to what the org chart says should exist.

The remedy is a scheduled access review cadence. Every six months, pull effective permissions for every user and compare against your role matrix. Correct anything that no longer reflects current responsibilities.

Practical Steps to Fix What Is Broken

• Build your task-to-role matrix first, on paper, before touching any configuration. Know what you are designing before you start designing it.
• Create custom permission sets at a granular level — view, edit, admin — for each functional area. Use nesting to give specific roles combinations of these sets rather than packing everything into one.
• Use the Effective Permissions page in Business Central constantly. It shows exactly what access any given user has and which assignment is granting it. Use it to validate during build and diagnose during support.
• Move permission assignment to the security group level. Direct user assignments make auditing messy and onboarding inconsistent.
• Enable the Change Log for sensitive master data tables — vendor bank accounts, customer credit limits, item costs. An immutable record of who changed what and when is basic due diligence for any financially controlled environment.
• Test every permission profile in a sandbox environment before it reaches production, and retest after each Business Central release wave.

How Vaden Consultancy Can Help

Our team has worked across a wide range of Business Central environments from fresh implementations where we design the permission model from day one, to inherited systems where the access structure has grown without a clear strategy. We also support organisations undertaking dynamics 365 business central development projects where custom objects need to be incorporated into the permission architecture cleanly and consistently.

In every case, the approach is the same: understand the business first, design around actual job functions, build with the tools the platform already provides, and put governance in place to keep the model accurate over time. We do not believe in over-engineering access control. We believe in building it correctly once and maintaining it simply.

If your Business Central permissions have drifted, if an audit is on the horizon, or if you are planning an implementation and want to avoid the shortcuts that create problems later we are happy to talk through where you are and what a structured approach would look like for your organisation.