Security Permission Overview in Business Central

If you’ve been managing security in Business Central for any length of time, you already know the drill. Permissions are granular, overlapping permission sets create unexpected access, and tracking down exactly who can see or edit a specific table has historically meant clicking through user after user. It’s tedious, error-prone, and, frankly, a pain point for admins, controllers, and IT teams for years.

Business Central 28 (specifically 28.1) introduces a permission overview feature that starts to change that. And if your organization has been relying on Microsoft’s out-of-the-box permission sets to get up and running, this is the tool that helps you go back and actually clean things up.

Key Takeaways:

• The permission overview is a targeted audit tool: Instead of digging into each user’s profile one at a time, you can now search by object, table, or permission type and see exactly which permission sets include that access. It’s a meaningful upgrade for anyone trying to do a real permissions review.
• Vendor bank accounts are a perfect example of the problem: In many default permission set configurations, read access to the vendor bank account table comes along for the ride inside roles that probably don’t need it. Banking, automation, full access, and others may all carry that permission. The overview makes it easy to spot this and ask the right question: Does this role actually need this access to do its job?
• Multiple overlapping permission sets make security filters tricky: If a permission is coming in through several different sets and different users belong to different combinations of them, a security filter alone may not cleanly remove visibility for everyone. That’s why it’s worth understanding the full picture before you start editing, which is exactly what the overview gives you.
• Segregation of duties starts with role clarity. Before removing or restricting anything, map out the actual roles within your business. Who needs to view vs. edit? Who needs indirect read access vs. direct? Building your own custom permission sets from a copy of an existing one is the recommended path forward rather than editing Microsoft’s defaults directly.
• Always test with a dedicated test user. Whoever owns security in your organization should have a test account they can log in as after making changes. This is the only reliable way to validate that what you intended to restrict is actually restricted and that the user can still do their job. Don’t skip this step; catching a misconfigured permission set in testing beats catching it after a data exposure.
• The process is: overview, copy, edit, test: Identify the permission set that has the access you want to change using the overview. Make a copy to create a custom version. Edit it, whether that’s applying a security filter or fully removing a permission. Then log in as your test user to confirm the change works the way you intended. That four-step loop is the framework worth building into your workflow.

Version 28 doesn’t solve every permissions headache, but the overview feature removes enough friction that there’s no good reason to keep putting off that security cleanup you’ve been deferring. Start with a high-risk table, run through the process, and build from there.