Digital products ·
Access begins at the boundary of someone else’s work
A manager may work with orders without needing every order in the company. Application roles and permissions establish what someone can do, which records they can use and the conditions that apply. I would agree those boundaries before designing the account screens.
A role name grants nothing by itself
“Administrator”, “manager” and “customer” sound clear until someone asks about a particular action. Can a manager change an agreed price? May a customer invite a colleague? Who can export contact details? When the answers remain informal, the developer has to invent the rules.
Begin with actions on a working object. An order might allow viewing, editing its contents, confirming, cancelling and exporting. Identify who may perform each action. Reading and editing are separate permissions. Exporting deserves its own decision even when the same fields already appear on screen: the resulting file can travel beyond the interface.
Specify the object as well as the action
Consider a hypothetical request system. A worker sees assigned requests, a team leader sees the team's requests and an owner sees an agreed wider overview. This is a design example, not a delivered client project. All three people “view a request”, but their data boundaries differ.
For each role and action, add a scope: owned, assigned, team or organisation. Then specify the object's state, such as draft, approved document or closed task. “May edit an owned draft” conveys more than “editors can edit”. These descriptions let a business discuss requirements before choosing a permissions library or platform.
Make the matrix resolve awkward cases
Use a small table with actions as rows and roles as columns. Each cell records whether access is allowed and under which condition. Avoid starting with dozens of job titles. Separate roles can add configuration work without adding value when the underlying authority is identical.
Test the table against questions that arise in ordinary work. What happens during temporary cover for a colleague? Can someone approve their own request? Who transfers ownership of an organisation? Record who authorises an exception and when it expires. Otherwise temporary access can quietly become permanent.
The interface presents the rule; the server enforces it
Removing a button helps someone navigate but does not prevent a data request. The OWASP authorization guidance calls for denying access by default and validating permissions on every request. The interface and server need to follow the agreed policy.
Specify the outcome of denied access in the development brief: the operation does not happen, the response does not reveal another person's records and the explanation is appropriate. Correct buttons cannot establish isolation between organisations. Verification must reach the object itself, including a direct request using its identifier.
Access changes when the work changes
Describe invitations, role assignments, team transfers and departures. Each operation needs a responsible person and an observable result. A removed team member should not retain access through an open page or an earlier permission; the revocation mechanism depends on the application architecture.
Agree what history to keep for sensitive changes: who changed access, when and on whose authority. That record helps investigate disputed access. Keep document contents and secrets out of it unless there is a separately justified requirement. Its purpose is to explain a decision, without creating another unrestricted store of information.
Verify a refusal as carefully as a success
Create test accounts for different roles and two organisations. Check an allowed action, the same action against another organisation's object, a role change and another request after access is revoked. Write the expected outcome first. Use invented records in a separate test environment.
The result should be a compact specification of roles, actions, data scopes, exceptions and verification scenarios. It complements customer portal planning and web application architecture. If you are commissioning an application or an internal system, start the development discussion with that matrix. It defines the first release more precisely than a list of screens.
From a use case to an app
If you need an app, we can define its core journey, roles, first release and constraints before development begins.