Start with the work a person must complete
Asking how many roles you need often comes too early. First describe a normal working day: who receives requests, assigns them, records results, and approves closure. Identify the information and actions required for each task.
The same job title may cover different data scopes. Two coordinators may perform identical actions for separate branches. Record that boundary: own cases, assigned team, branch, or the whole company. This makes the rule testable against a particular record.
Separate viewing, editing, approval, and export
'Has access to jobs' is ambiguous. It could mean reading a list, editing deadlines, changing prices, or downloading the entire register. Record these actions separately. For sensitive steps, specify conditions such as editing before submission for approval or exporting only an assigned branch.
Use a simple matrix: actions in rows, working roles in columns, and a data scope attached to each permission. Start with the main workflow and place exceptions alongside the relevant rule rather than in an unclear 'as needed' note.
- View details and search records.
- Create a case and edit selected fields.
- Assign responsibility or change status.
- Approve, reject, or return for completion.
- Export data and download attachments.
- Manage users and assign permissions.
Define cover arrangements for approvals
For each approval, consider what happens when the responsible person is unavailable. Who may act instead, during which period, and for which cases? Cover should address a specific operating need rather than expose an absent colleague's entire account.
Decide what happens when approved information changes. If someone changes an amount or the work scope, does the original approval remain valid? The process owner should decide and provide an example. A clear rule helps both delivery and later exception handling.
Hiding a button is not access control
Signing in establishes identity; authorization determines permitted actions. The server must check permission when processing a request, including one made through a direct link. A new feature should not automatically expose protected data: access needs a defined rule.
Ask the development team to verify allowed and forbidden cases. Demonstrating that a technician can open their own visit is insufficient. Tests should confirm that they cannot open another person's case, download its attachment, or edit a restricted field.
Trace important decisions without copying everything
Operations may need to establish who assigned a case, changed a price, approved an exception, or modified permissions. Choose events that help explain decisions and define who may inspect them. Change history should answer a concrete question rather than simply accumulate records.
Technical logs should exclude passwords, access tokens, and unnecessary personal data. Agree access and retention according to purpose. Distinguish user-facing case history from diagnostic records; their readers and contents may differ.
A job change is also an access change
Define who requests, approves, and applies permissions. Cover joining, team transfers, temporary support, and departure. For a transfer, adding a new role is only part of the task: decide which old permissions are no longer needed.
Prepare a user list showing the reason for each access grant and its decision owner. Record an end date for temporary access. Before launch, representatives of each role should complete real work tasks and try scenarios the system must refuse.
- Who approves access to each data group?
- What changes when a person moves to another branch?
- How does temporary cover end?
- Which open cases need handover on departure?
- How are permissions checked after adding a feature?
Design access rules alongside the workflow
A clear permission brief helps staff work without constant exception requests while defining responsibility boundaries. You do not need to choose an implementation method in advance. You need concrete tasks, data scopes, and someone who can decide ambiguous cases.
If you are planning an internal system, bring its main workflow and examples of what each person may and may not do to a consultation. At DAVOND, we can review these rules alongside the system design so permissions reflect operations and testable situations.