Problem
There is a statement I hear often in the Business Central community:
“The standard permission sets are not useful.”
I disagree. Not because Microsoft permission sets are perfect—they are not—but because most of the time, they are not actually the problem. The problem is how they are being used.
What typically happens is this. A standard permission set is assigned, a user gets more access than expected, and something does not behave quite right. From there, the conclusion becomes, “We need to rebuild everything from scratch.”
So that is what happens. Permission sets are copied, modified, layered, and re-layered. Over time, no one really knows what any of them are doing anymore. At that point, the system is not secure. It is just fragile.
What I See in Real Environments
When I walk into a system, I usually find the same patterns. D365 FULL ACCESS or SUPER has been assigned temporarily and never removed. Permission sets have been cloned without any consistent naming or structure. Multiple sets are stacked on users without a clear understanding of how they interact, and there is no real distinction between base access and overrides.
Most importantly, no one is validating results using Effective Permissions. Everything appears to work until someone asks a question—and then no one has a confident answer.
Solution
The Righter Way is not to throw out what Microsoft provides. It is to use what you already have, understand it, and then decide if it truly does not work. We have already paid for the platform, and we should start there.
There are absolutely cases where standard permission sets do not meet the requirement. That is real. But in my experience, those cases are far fewer than people think, and they are often identified too late in the process—or worse, assumed from the beginning.
The Righter Way: Layered Permission Architecture
Instead of rebuilding everything, use a structured approach.
Step 1: Start with Microsoft-provided permission sets
These become your base. They are intentionally broad because they are designed to support full processes, prevent features from breaking, and evolve with the product over time. When you remove them entirely, you take on the responsibility of maintaining that coverage yourself, including keeping up with new objects and changes introduced by Microsoft.
Step 2: Build a composable permission set per role
Define the role in one place. Reference Microsoft-provided permission sets and then add anything that is missing for how your organization actually operates. This becomes your role definition, and it should be understandable without having to trace across multiple assignments.
Step 3: Override using Direct Permissions
Within that same permission set, refine access using Direct Permissions. Add Include where additional access is needed and use Exclude where access should be removed. This allows you to enforce least privilege without copying entire permission sets and without losing alignment with Microsoft updates.
A Small but Critical Detail
This is where most designs fail, and it is worth being very clear about how Business Central evaluates permissions.
Within a single permission set, Exclude overrides Include. However, when multiple permission sets are assigned to a user, Include wins. This means that creating a separate “exclude” permission set will not behave the way many expect. If another assigned permission set includes that access, the user will still have it.
That is why overrides need to live inside the same permission set rather than being spread across multiple ones. This keeps the behavior predictable and aligned with how the platform actually resolves permissions.
When You Do Need Multiple Permission Sets
There are valid scenarios where more than one permission set is required. For example, a user may need to select G/L accounts on transactions but should not be able to view G/L entries. In another case, a user may need to work only with vendors tied to a specific posting group.
These are real requirements, but permission sets do not behave like a clean hierarchy. They do not nest in a predictable way. Includes combine, and excludes do not reliably restrict access across multiple sets. Because of this, the outcome depends on the exact combination assigned, which is where many designs become difficult to reason through.
Even in these cases, most requirements can still be met using Microsoft-provided permission sets with the correct structure and use of Direct Permissions. The answer is rarely “more permission sets.” It is almost always better structure and more intentional design.
Here Is the Part I Think We Skip Too Quickly
When something does not work immediately with standard permission sets, the reaction is often to build a custom solution, bring in another tool, or start over entirely. That may be necessary in some cases, but it should not be the starting point.
A better approach is to begin with Microsoft-provided permission sets, structure them correctly, apply Direct Permissions intentionally, and then test the outcome. Only after working through that process should you decide whether the requirement truly cannot be met with what the platform already provides. In many cases, it can.
Why This Approach Holds Up
This approach keeps you aligned with Microsoft updates, which is one of the most overlooked advantages. As permission sets evolve, your base evolves with them, reducing the risk of missing access required for new functionality.
It also avoids duplicating large amounts of logic that you would otherwise need to maintain. Instead of owning every permission decision, you are refining what Microsoft provides. This results in a model that is easier to explain, easier to test, and easier to support over time, with fewer moving parts overall.
Where This Approach Does Not Work
There are situations where this approach will not fully meet the requirement. Highly regulated environments, field-level restrictions, or complex segregation of duties may require additional design or even external tools.
Those scenarios are real, but they should be identified after working through what Business Central already offers. Starting with a custom or third-party solution too early often introduces unnecessary complexity before the standard capabilities have been fully explored.
The Missing Step: Validation
Before assigning permissions to real users, validation needs to be part of the process. Use Effective Permissions to confirm the outcome, test with a dedicated user, and walk through key processes end to end.
This step is frequently skipped, and it is where many permission issues originate. Without validation, even a well-designed structure can produce unexpected results.
Final Thought
Microsoft-provided permission sets are not perfect, but they are also not the liability they are often made out to be. When you start with what you already have, structure it intentionally, override within the same permission set, assign additional permission sets carefully, and validate the results, you move from a permission model that feels unpredictable to one you can actually trust.
One Step You Can Take Today
Pick one role, such as AP Clerk, and instead of rebuilding it, start by understanding it. Identify which Microsoft permission sets are being used, what has been added, and what has been overridden. Then simplify. In many cases, you will find you need less than you think.
Created as part of Sharing the Righter Way, this article combines my Business Central experience with AI-supported research and drafting. AI helps me explore options and accelerate analysis, while every conclusion and recommendation reflects my own professional judgment.
