Roles and permissions
Start with the smallest set of roles that explains the work. For a client workspace, that may be customer, staff, and administrator. Define their actions in plain language before asking for the interface.
Write an access table
Section titled “Write an access table”| Action | Customer | Staff | Administrator |
|---|---|---|---|
| Read a request | Own requests | Assigned requests | Requests within their managed workspace |
| Change status | No | Assigned requests | Managed requests |
| Change access | No | No | Yes |
This is an example policy to implement and test, not a set of automatic default roles.
Include agents
Section titled “Include agents”An agent acting for a person should use only the context and actions permitted for that task. Specify when it can save a draft and when a person must approve an external action. Verify those controls in the working app rather than relying on instructions alone.
Test the boundary
Section titled “Test the boundary”Try direct record links with the wrong account. Confirm that denied actions stay denied when the interface is bypassed. Repeat the checks after changing ownership or role rules.