The scope calls for “user and administrator areas”. In practice, a user might be a resident, a branch employee or someone approving a case. Each needs different information and actions.
Before a supplier prices the account area, describe what those people do. The number of account types alone does not explain the complexity.
Start with a simple table
This example is a starting point for a request-handling system. Adapt the roles to your own process.
| Role | Can see | Can change |
|---|---|---|
| Applicant | Their own cases | Agreed details before a specified stage |
| Staff member | Cases in their unit | Status and notes within their remit |
| Coordinator | Cases across assigned units | Allocation and approval |
| Account administrator | Accounts and assigned roles | User access |
Do not assume that someone managing accounts needs access to every case's contents. Each permission should follow from a task they perform.
Describe the account lifecycle
Who creates an account? How does someone recover access? What happens when they change jobs or leave? Is cover for an absent colleague temporary? Who checks that previously assigned roles are still needed?
Include staff who work across several units. Those cases may need more thought than a standard split between user and administrator.
Check the boundaries as well as access
During acceptance, test both permitted and prohibited actions. A user can see their own case but cannot open someone else's; staff in one unit cannot change another unit's records. The agreed table supplies the criteria.
Budget for account administration and any connection to existing sign-in services. If someone says “login is already included”, ask whether that covers role assignment and the organisational situations you described. A successful sign-in is only one part of making access work correctly.
Every number in this article, plus thousands of other contracts, is in the database.
Open the database