BlogInternal permissions
Roles and permissions: who views, changes and approves in your system
A hidden menu does not prove an action is blocked. Define permissions by task and verify each role's outcome.
Test worksheet: Internal roles: viewing, changing and approving
A hidden menu does not prove an action is blocked. Define permissions by task and verify each role's outcome. Record inputs, expected outcome, evidence, owner and observed result.
Start with decisions that affect money or data
“Administrator” and “employee” are often too broad. In a distributor, sales needs to prepare a discount, finance can approve it and the warehouse fulfills the approved order. Write these actions before naming roles. Include information exports and rule changes: both can affect the business even without directly modifying an order.
Business Central distinguishes read, insert, modify, delete and execute permissions. OWASP recommends least privilege, default denial and permission validation on every request. Test the outcome of an action rather than the existence of a button. Combinations of roles also need review.
Fictional example: discount on order P-606
Sales requests a 12% discount for P-606. The rehearsal rule lets sales propose it, but finance must approve discounts above 8%. The same person cannot approve their own request. These fictional thresholds test the process; they are neither margin advice nor an already implemented capability.
If the salesperson receives a temporary supervisor role too, requester and approver separation must remain. A denied attempt keeps the previous price and leaves an identifiable request. A finance approval records who decided and which order version they reviewed. A subsequent quantity change requires the agreed review rather than silently reusing an old approval.
| Action | Sales | Finance | Warehouse |
|---|---|---|---|
| View order | Yes, for its work | Yes, for review | Yes, fulfillment details |
| Request 12% | Yes | Not needed for this rehearsal | No |
| Approve own request | No | No | No |
| Approve another person's request | No | Yes, under agreed criteria | No |
| Change a user's permission | No | Not merely as an approver | No |
Test each account's effective permission
Use rehearsal accounts with a single role, then actual combinations. Check an action started before a permission change and completed afterward. Define when revocation takes effect in the product and what happens to pending work. Recording that dependency is more useful than promising an untested immediate effect.
| Case | Expected result | Evidence |
|---|---|---|
| Sales requests 12% for P-606 | Pending request without applied discount | Order and request |
| Sales attempts self-approval | Denied with unchanged price | Attempt and comparison |
| Finance approves another person's request | Discount applied once to the reviewed version | Decision and version |
| Warehouse attempts price change | Denied even with knowledge of the route | Request and final state |
| Finance role is removed | New attempt cannot retain the removed permission | Time and effective-access test |
| Approval retried after lost response | Same decision without duplicate change | Approval reference |
Give exceptions a duration and owner
Holiday cover may need temporary permissions. Record reason, start, end and who verifies their removal. If nobody can approve during an absence, agree on an alternate; sharing a password is not a substitute. Emergency access needs a separate procedure and a subsequent check of actions taken.
Review access inherited from groups, roles and integrations. Effective permissions may depend on licensing, configuration and custom rules. If the current product supports the matrix, configure and test it before requesting another system. If a critical separation is missing, document the specific case when comparing alternatives.
Keep a matrix you can maintain
Update the matrix when a task changes, not just when someone joins. Link actions to a change audit log, test employee offboarding and retain owners for digital keys. Customer portals have another boundary: they must also prevent access to other customers' information.
The downloadable worksheet proposes ten internal tests and leaves results empty. Bring approval rules, current roles and an anonymized exception to a free consultation for cybersecurity. We can review which actions need verifiable control and which depend on system configuration.
Frequently asked questions
It does not demonstrate authorization. A user may attempt the action through another screen or a direct request. Check that the system denies the change and preserves the correct data using the product's available functions and tests.
Not merely because of the job title. Identify necessary actions and separate user administration, business approval and viewing. Permission to approve discounts does not automatically justify changing the rules that limit them.
Run the matrix with effective group and role combinations. Check permissions that accumulate or exclude each other and self-approval restrictions. An individual account may have more access than any one role viewed separately.
Define who can temporarily own the decision and for how long. If work must wait for approval, make that explicit. Sharing credentials removes attribution and does not create a valid substitution rule.
Sources
- Define granular permissionsMicrosoft
- Authorization Cheat SheetOWASP
Last updated: