[Blog]()Internal 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. **[Jonathan Perez]()**Co-founder · Design, product and sales October 8, 2026 · 7 min read **Short answer** Define permissions around business actions: view, create, modify, approve, cancel and export. Assign roles by responsibility and test allowed work as well as attempts that must fail. If approval requires another person, that separation must survive a user holding several roles. ## 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. [Download CSV worksheet]() In this guide - [Start with decisions that affect money or data]() - [Fictional example: discount on order P-606]() - [Test each account's effective permission]() - [Give exceptions a duration and owner]() - [Keep a matrix you can maintain]() ## 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. ## Review who changes and who approves A request that needs a separate approver tests roles better than a screen list. Bring it to a free consultation with allowed actions and temporary cover so we can define which requests should succeed or be rejected. - Actions that view, change, approve or export - Current roles and groups with temporary cover - One request requiring a different person to approve [Book a free consultation]()[Ask on WhatsApp]() Related - [Cybersecurity for businesses]() - [Hosting, backups and maintenance]() ## Frequently asked questions ### Is hiding a button sufficient? 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. ### Should a manager have every permission? 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. ### How do we test users with several roles? 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. ### What if there is no alternate approver? 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 1. [Define granular permissions]()Microsoft 2. [Authorization Cheat Sheet]()OWASP Last updated: October 8, 2026 ## Keep reading [Access controlOct 8, 2026 ### Employee offboarding: accounts, sessions and integrations to review]()[ProductionOct 8, 2026 ### Purchase orders: approvals, changes and verifiable receiving]()[PortalsOct 8, 2026 ### Portal permissions: each customer sees permitted records]() --- Canonical: https://nightlysoftware.com/en/blog/business-system-role-permissions Updated: 2026-10-08 Description: Design action-based permissions and test approvals, exports and role changes. Includes an internal-user permission matrix for your business.