Design permissions around records and business actions

A team lead may edit requests for one site but only view requests elsewhere. A reviewer may approve a request without permission to change its attachments. A single administrator-or-user distinction cannot express these needs. Start with the business action and the record involved, then decide which conditions make the action acceptable.

Create a business permission matrix

List actions in terms people recognize, such as assign, approve, reopen, export, and delete. For each action, define the record scope and required relationship. Ownership, site membership, delegated responsibility, and current state may matter independently. Do not assume that permission to edit implies permission to approve.

OWASP distinguishes authentication, which establishes identity, from authorization, which determines permitted access.[4] A successful login does not answer whether this person can act on this record. Use that distinction when reviewing requirements and when explaining an access denial to staff.

Enforce rules beyond visible controls

OWASP recommends denial by default and permission validation on every request.[4] Hidden buttons improve usability but are not the enforcement boundary. Apply checks when the server reads or changes data. Include downloads, search results, direct record links, and application programming interfaces, not only the main editing screen.

PostgreSQL row security can restrict visible or changeable rows, with default denial when enabled and no applicable policy exists.[7] The table owner is typically outside those policies.[7] Treat database controls as one layer. Verify the identity and privileges used by the application rather than assuming row security covers every connection.

Hypothetical example: a multi-site repair queue

A hypothetical repair service lets coordinators assign jobs only within their own sites. Regional reviewers can approve cross-site transfers, but they cannot change repair notes. The permission matrix records these as separate actions instead of creating one powerful regional role for convenience.

An export request follows the same site restrictions as the queue. A bulk reassignment checks each affected record before commitment. This model requires more tests than a broad role switch, but it makes the allowed work easier to explain and audit.

Test denials and changing relationships

Build tests around allowed and forbidden combinations. Include a worker who changes sites, a revoked delegate, and a record whose owner changes during review. Decide whether a long-running export rechecks access or works from an explicitly authorized snapshot. Make that choice visible in the design.

Fine-grained rules can become difficult to maintain. Prefer reusable policies and a small vocabulary of business actions over scattered special cases. Give support staff a safe explanation of denied access without revealing sensitive record details. Review exceptional grants so temporary access does not become permanent by neglect.

• Map each business action to its record scope.
• Separate view, edit, approval, export, and deletion.
• Check server routes and background execution identities.
• Test denied access using another site or owner.
• Define revocation behavior for queued and long-running work.