In Microsoft Dynamics 365 Business Central, understanding how inherent permissions behave on the Effective Permissions page is fundamental to any security strategy. When a permission’s Source displays Inherent, the rights are compiled inside the object itself; they override your configured permission sets, including any Exclude records. Below is a concise breakdown of what that means and how to regain control.
What Makes a Permission “Inherent”?
Developers add the InherentPermissions attribute to a table, page, report, or codeunit. When the extension is compiled, the attribute becomes part of the object. At runtime the platform injects these permissions on top of the user’s permission sets; the admin client can’t edit or suppress them.
Why the Admin Can’t Remove Them
| Objective | Possible in UI? | Required Action |
| Remove or narrow the right | No | Re-compile the extension without—or with tighter—InherentPermissions. |
| Override with Deny/Exclude | No | Deny/Exclude is evaluated before inherent rights are applied. |
| Limit data exposure indirectly | Partly | Redesign: move data to a separate table, or run the object under a service account and surface only required fields. |
Technical Paths Forward
(See disclaimer at the end.)
- Re-compile Your Code
- Comment out or adjust the InherentPermissions attribute.
- Publish a new build.
- Verify results in Effective Permissions.
- Request Changes from the ISV
- Document the risk (audit, segregation of duties, privacy).
- Open a ticket for an updated package or a configuration toggle.
- Wrap or Replace the Object
- Create a wrapper page/report without inherent access.
- Run the original object under a service account; expose data through the wrapper.
- Learn more https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-inherent-permissions
The Righter Way Checklist
- Identify the object ID containing the undesired inherent rights.
- Confirm whether the object is Microsoft, ISV, or custom.
- Record the business impact.
- Schedule development or submit the vendor request.
- Re-test permissions after deployment.
Closing Thoughts
Inherent permissions are not a bug and they are not bad—they’re a deliberate design choice embedded in code. Inherent permissions are best for use with small dedicated procedures or system tasks that don’t risk data exposure to users. Consider changing the code working with those who own it, and your security model returns to your control.
Want to learn more about permissions in Business Central, start with this first of four blogs on the topic:
Moving Beyond User Groups! Do we need to? – Sharing The Righter Way – Cynthiapriebe.com
That’s the disciplined, Righter WayTM to secure your Business Central environment.
Disclaimer: I’m not a developer. The code-level steps described above come from publicly available documentation and community guidance I’ve studied. Engage a qualified developer and test in a sandbox before applying changes to production.
