Do not define an internal system’s permissions with a list of job titles alone. Specify who can perform which action, on which record, in which state and under which conditions. Then decide what happens after rejection, amendment or an approver’s absence. This turns an approval workflow into testable business rules rather than buttons that look convincing in a demonstration.
The scope here is a portal for an agreed operational process. Internal Operations Portals & Dashboards can cover defined requests, roles and data without becoming a full enterprise resource planning system or implying a security certification.
A role does not define the record boundary
Two supervisors may approve the same type of request, but for different branches. An employee may read their own requests without seeing colleagues’ requests. Your matrix therefore needs role, action and data scope, not just ticks beside “view” and “edit.”
Also distinguish signing in from permission to act. OWASP’s authorization guidance recommends denying access by default and validating permissions on every request. Hiding an approval button is insufficient if the action remains available through a direct link or API. This is a specific acceptance requirement, not a substitute for specialist security assessment where needed.
Include exports and attachments. A screen can correctly prevent editing another branch’s request while an unrestricted download still reveals every branch’s information. The system’s different outputs need consistent boundaries based on the approved operating policy.
Model states before screens
Use states with clear meanings: draft, submitted, information required, approved, rejected and cancelled. For each transition, identify the actor, necessary inputs, resulting state and notification recipient. A single “in progress” label can conceal several responsibilities and make it impossible to identify where work is waiting.
Ask what happens after a material amendment. Does an approval remain valid when the quantity or beneficiary changes? Does a returned request go back to its previous reviewer or restart the sequence? These are decisions for the process owner. A developer should not choose whichever behavior is easiest to implement.
Product Discovery & Requirements can record the rule, a positive example and a counterexample. “The supervisor approves requests” is weaker than “the current branch supervisor may approve a submitted request created by someone else, within their agreed limit, after required information is complete.”
Worked hypothetical: a branch materials request
Imagine a business organizing requests for operational materials. An employee prepares the request, a branch coordinator reviews it, and a supervisor can approve an illustrative amount up to SAR 5,000. Requests above that amount go to another designated owner. This threshold is a teaching example, not financial advice or a recommended business policy.
An employee submits a request for SAR 4,800. The coordinator checks the information without issuing final approval. The supervisor approves it. The employee then increases the quantity, taking the value to SAR 5,400.
Under the example’s proposed rule, the earlier approval becomes invalid and the amended request follows the higher approval route. The system must not treat a material change as a harmless text correction.
During the supervisor’s leave, an authorized owner appoints a substitute for a defined period and branch scope. Nobody shares the supervisor’s password. The substitute does not automatically gain permission to change approval limits. The decision record identifies the person, their effective capacity at the time, the timestamp and any required exception reason. Decisions remain reviewable after delegation expires.
Test prohibited actions as well as successful ones
Ask Software Quality Assurance to demonstrate that the intended actor can complete the work and that other actors cannot cross the agreed boundary. Acceptance cases should include:
- An employee cannot approve their own request when policy prohibits it.
- A supervisor cannot read or export another branch’s restricted records.
- Material changes invalidate earlier approval as agreed.
- Expired delegation prevents new decisions without erasing past decisions.
- Simultaneous attempts by two approvers do not create contradictory outcomes.
- Rejection explains the next step without exposing restricted information.
For external connections, API Integration & Development should define the service account’s authority and the states it can change. Giving an integration unrestricted administrative rights simply to make the first test pass leaves the business rule unenforced at an important entry point.
Use an agreed test environment and authorized data. The acceptance exercise should not involve trying to defeat controls on systems outside the approved scope. Record the expected refusal and evidence without unnecessarily exposing sensitive content in screenshots or logs.
Exceptions need a controlled route
A workflow may legitimately require urgent processing or correction of an earlier decision. Define who requests the exception, who approves it and which information cannot be changed after execution. Avoid indefinite “temporary” administrator access and shared accounts that hide the real actor.
Before go-live, rehearse the process with representatives of the actual roles. Ask each person why a request appears in their queue and why another action is unavailable. If explaining routine behavior always needs a developer, the rule or interface may still be unclear.
Name an owner for reviewing permissions after employees move roles or branch responsibilities change. The acceptance document describes the initial arrangement; it is not a reason to leave that arrangement untouched indefinitely.
Frequently asked questions
Can one person hold several roles?
Yes, if policy permits it. Test the interaction between those roles. Holding both does not automatically permit self-approval or remove an intended separation between review and approval.
Are screen-level permissions enough?
Record, action and export restrictions may also be necessary. Derive the scope from the actual information and verify enforcement beyond the visible interface.
What happens if all approvers are absent?
Use an agreed escalation or substitute route. Absence does not authorize automatic approval, and the technical team should not choose a replacement decision-maker on its own.
Does an approval history establish legal compliance?
It provides operational evidence within its defined scope, not certification. Specific legal or regulatory requirements need qualified review and a separate decision about evidence and retention.
Begin with one approval process and document its states, boundaries and exceptions before commissioning screens. That produces a clearer development scope and a more meaningful acceptance exercise.
Technical reference
- OWASP: Authorization Cheat Sheet, reviewed 26 October 2026. The approval threshold and delegation arrangement are hypothetical.