Define access around specific actions and records, not just job titles. Start with the minimum access a role needs, check it on the server, and test what the role must not be able to do.
Write down actions before roles
Admin and employee are usually too broad to describe how an operation works. A coordinator may assign a task but should not change payment settings. A field worker may update one job without seeing every customer. A manager may approve an exception without managing user accounts.
List the actions that matter: view, create, edit, assign, approve, export, and delete. Then identify the records each action can touch. This separates the ability to use a feature from permission to use it on a particular customer or team.
Use a small decision matrix
For an illustrative service operation, give field workers access to their assigned jobs, coordinators access to the dispatch queue, and managers access to approvals. Treat bulk exports and account administration as separate decisions.
Write one sentence for every permission that feels ambiguous. For example: a coordinator may reassign jobs within their location, but moving a job to another location requires manager approval. That sentence becomes a requirement the team can demonstrate.
Check permissions where the action happens
OWASP recommends least privilege, denial by default, and authorization checks on every request. Hiding a button is not a substitute for checking whether the signed-in user is allowed to perform the requested action. Source: OWASP authorization guidance.
Ask the delivery team to demonstrate a denied request as well as an allowed one. A worker should not gain access to another job simply by changing a record identifier in a link. This is a technical acceptance question with a direct business consequence.
Plan for people changing responsibilities
Access should have an owner after launch. Decide who approves a new user, who removes access when someone leaves, and how temporary responsibilities expire. Shared accounts make those changes harder to attribute to an individual.
For a small pilot, a limited shared team login may be a deliberate constraint. Document that constraint and the point at which individual accounts become necessary. Do not describe a shared login as a system with individual accountability.
What to bring to discovery
Bring a list of roles, three representative records, and examples of actions each role must not perform. Include a transfer, a cancellation, and an exception that needs approval.
Our preferred result is a permissions matrix that operations and engineering can both read. It should be specific enough to test, but small enough that the business owner can spot an accidental grant of access before it ships.
Technical references
The business checklists above reflect our proposed approach. The following primary sources support the technical points cited in the guide.