The Problem with "Bottom-Up" Security
Most permissions are built "bottom-up"—a user says they can't do something, so an admin grants them a specific right. Over time, this creates a "Spaghetti" structure where no one knows why and how anyone has access to anything.
By starting with an organizational chart, you shift to a "Top-Down" approach. You define who a person is in the organization before you define what they can do in the software.
Step 1: Mapping the Organizational Chart
The first task is to define every department that interacts with Business Central—Finance, Sales, Purchasing, Warehouse, etc. Under each department, you list the specific job functions (not the names of people, but the roles themselves).
-
Example: In the Purchasing Department, you might have a Purchasing Manager, a Senior Buyer, and a Junior Buyer.
Step 2: The Assessment Session
Once the roles are defined, you meet with "Key Users" or Department Heads, the people that know what job they should be doing. You don’t ask them about tables or pages; you ask them about tasks.
-
"What does a Junior Buyer do on a Tuesday morning?"
-
"Who is responsible for approving a vendor’s bank account change?"
This information allows you to create a Permissions Matrix. On one axis, you have your organizational roles; on the other, you have the business tasks.
Step 3: From Tasks to Roles
By mapping tasks to roles, you create a modular blueprint. This prevents "Permission Creep". The phenomenon where users accumulate rights as they move through the company without ever losing the old permissions. And if the definition of a role changes in the future, it’s easier adding or taking out the specific task instead of redefining the whole role.
If a Junior Buyer is promoted to Senior Buyer, you simply swap their organizational role in the framework. Because the permissions are linked to the role and not the individual, the transition is clean, secure, and documented. If the Senior Buyer gets the responsibility to maintain vendors which he didn’t have before, you just have to add that one specific task to the role instead of creating a new permission set with the vendor table in it.
Why Auditors Love This Approach
When an auditor asks, "Why does John Doe have access to the General Ledger?" a typical admin might struggle to find the answer.
With a framework based on an org chart, the answer is simple:
-
John Doe is a Senior Accountant (Organizational Role).
-
The Senior Accountant role is responsible for Month-End Closing (Task).
-
The Month-End Closing task requires Read/Write access to the G/L (Permission Set).
This level of transparency makes audits faster, cheaper, and significantly less stressful.
Conclusion: Business First, Software Second
A permissions framework isn't a technical project; it's an organizational one. By using your company's structure as the foundation, you ensure that your Business Central security grows with you, rather than becoming a bottleneck.
Ready to build your own matrix? In our whitepaper, "Authorizations in Business Central," we provide a step-by-step guide to moving from an org chart to a live production environment. Download it today to get started.
