Building a Permissions Framework: Why an Org Chart is Step One for Security

The problem with bottom-up security

Most permissions are built bottom-up. A user says they cannot do something, so an admin grants them that specific right. Over time this creates a spaghetti structure in which nobody knows why anyone has access to anything.

Starting from the organizational chart turns this into 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: map the organizational chart

First, list every department that works in Business Central: finance, sales, purchasing, warehouse and so on. Under each department, list the job functions. Not the names of people, but the roles themselves.

• Example: the purchasing department might have a Purchasing Manager, a Senior Buyer and a Junior Buyer.

Step 2: the assessment session

With the roles defined, sit down with key users or department heads: the people who know what each job involves. Do not ask them about tables or pages. Ask about tasks.

• “What does a Junior Buyer do on a Tuesday morning?”
• “Who is responsible for approving a change to a vendor’s bank account?”

This gives you a permissions matrix: organizational roles on one axis, business tasks on the other.

Step 3: from tasks to roles

Mapping tasks to roles gives you a modular blueprint. It prevents permission creep, where users collect rights as they move through the company without ever losing the old ones. And when a role changes later, you add or remove one task instead of redefining the whole role.

If a Junior Buyer is promoted to Senior Buyer, you swap their organizational role in the framework. Because the permissions belong to the role and not to the person, the transition is clean, secure and documented. If the Senior Buyer later becomes responsible for maintaining vendors, you add that one task to the role, instead of creating yet another permission set with the vendor table in it.

Step 4: translate the matrix into Business Central

Only now do you open Business Central. The matrix translates into objects fairly directly:

• Each task becomes a permission set, or a small group of them, for example “Maintain vendors” or “Post purchase invoices”. Keep them narrow so they can be reused across roles.
• Each job role becomes a collection of those task sets. Natively, you can use security groups for this. Security groups are based on Microsoft Entra groups and have replaced the legacy user groups.
• Users get roles, not individual sets. Direct assignments to individual users are the first step back to spaghetti.

Native security groups get you part of the way. They bundle permission sets for many users, but they do not know about departments, do not route a role change through an approval and do not remove a role on an end date. Those parts of the framework still sit in your procedure, your spreadsheet or a dedicated tool.

Why auditors love this approach

When an auditor asks, “Why does John Doe have access to the general ledger?”, a typical admin has to go digging.

With a framework based on the org chart, the answer is simple:

1. John Doe is a Senior Accountant (organizational role).
2. The Senior Accountant role is responsible for month-end closing (task).
3. The month-end closing task requires read and write access to the G/L (permission set).

That level of transparency makes audits faster, cheaper and far less stressful. It also makes segregation of duties easier to check, because you can review conflicts per role instead of per individual.

Keep the framework alive

A framework is only as good as its upkeep. Build in three habits:

• Changes go through the role, never around it. New access is either a task added to a role or a new role, with an approval.
• Temporary access has an end date. Cover for holidays or projects is granted with a date on which it ends.
• Review per role. Check periodically whether each role still matches the job and whether any role combines conflicting tasks.

How Authorization Box fits the framework

Authorization Box, 2-Controlware’s web based application for managing Business Central permissions, is built around this same model:

• An organization chart with departments and organization roles, where permission sets are assigned to the roles.
• Authorization requests to assign or revoke an organization role for a user, with a start date and, if applicable, an end date, and with approvals when you require them.
• Authorization Monitoring that analyzes critical permissions and segregation of duties conflicts, with a view of the results per organization role.
• Change logs that show who changed what and when it was synchronized to Business Central.

Conclusion: business first, software second

A permissions framework is not a technical project; it is an organizational one. By using your company’s structure as the foundation, your Business Central security grows with you instead of becoming a bottleneck.

Ready to build your own matrix? Our whitepaper “Authorizations in Business Central” gives a step-by-step guide from org chart to live production environment. Download it to get started.