Separate application roles from factory authority
Application roles express business authority: request equipment, approve a claim, assign a task or record delivery. Factory and platform authority governs development work, repository integration, infrastructure, accounts and policy. Permission to operate the factory does not grant a business approval inside the application.
Start with the record owner and the specific action. Queue access, assignment, approval and completion are distinct permissions. A person can hold several roles while still failing a required separation-of-person check.
Business role + record + state
Repository policy + development authority
Factory authority does not grant business approval.
Authored illustration of workflow rules and responsibilities.
Write the permission before the action
The matrix below is a worked business specification, not executable source. State read visibility as well as write authority. Ordinary equipment requesters see their own requests; reviewer and coordinator roles grant queue access. Completed facts remain visible only through those permissions.
Actor and authorityEmployee requester
- Whose record / action
- Own request: create and edit
- Allowed state
- Awaiting approval for edits
- Protected fields / refusal
- Item, reason and requester protected after approval; unrelated records unreadable.
Actor and authorityAuthorised reviewer
- Whose record / action
- Another person’s eligible equipment request: approve
- Allowed state
- Requested; active catalogue item
- Protected fields / refusal
- Refuse self-approval and repeated approval; lock reviewed amount under new policy.
Actor and authorityFinance approver
- Whose record / action
- New request above €1,000: additional approval
- Allowed state
- Awaiting Finance, after ordinary approval
- Protected fields / refusal
- Actor differs from requester and initial approver; amount and prior decision stay protected.
Actor and authorityOperations coordinator
- Whose record / action
- Eligible request: record delivery with asset tag
- Allowed state
- Every required approval complete
- Protected fields / refusal
- Refuse early delivery or empty tag; protect completed delivery facts.
Actor and authorityHR coordinator
- Whose record / action
- Starter’s unfinished task: assign or reassign
- Allowed state
- Unfinished
- Protected fields / refusal
- Protect completed task details; HR role alone cannot complete another person’s task.
Actor and authorityCurrent assignee
- Whose record / action
- Own assigned task: complete
- Allowed state
- Unfinished
- Protected fields / refusal
- Refuse completion by another ordinary teammate; completion locks details.
Actor and authorityExpense reviewer
- Whose record / action
- Another person’s Submitted claim: return with reason
- Allowed state
- Submitted only
- Protected fields / refusal
- Keep original details, actor and time; refuse return of Approved or Paid claims.
Actor and authorityOriginal expense submitter
- Whose record / action
- Returned claim: submit one linked replacement
- Allowed state
- Returned for correction; no direct replacement yet
- Protected fields / refusal
- No parallel branches; fresh review; never copy approval/payment facts.
Reuse the matrix
Create one entry for each meaningful action and read path. Replace broad labels such as “admin can manage everything” with the actual authority, record scope, state and protected fields. Resolve overlapping roles explicitly.
For onboarding, Sam’s relationship as the new starter does not grant access to everyone else’s tasks. Ordinary teammates see their assigned work and necessary starter details; HR has explicit wider visibility. After HR reassigns unfinished work, only the new current assignee can complete it.
For an expense correction, preserve the returned original and restrict replacement submission to its original submitter. A replacement starts at Submitted and receives fresh review by someone other than the submitter; Alex may review again. Only the current replacement progresses. Finance records payment with a reference after approval; this action does not transfer money. Reviewer and Finance permissions do not inherently require different people in this example.
Blank permission matrix entry
Copy one entry for each action or read path, then specify a permitted case and an expected refusal.
Who and whose record
- Actor
- Role or person, including overlapping roles.
- Record owner and visibility
- Whose record? Who may read it and its linked previews?
Action and safeguards
- Action
- Create, edit, approve, assign, complete or another action.
- Required application authority
- Specific business permission; keep factory authority separate.
- Allowed state
- Conditions before the action.
- Protected fields
- Which facts remain unchanged, and from when?
Permitted and refused cases
- Permitted scenario
- Actor, record, starting state and expected result.
- Expected refusal
- Actor or state that must fail, and what remains unchanged.
Try both sides of every rule
Test the permitted case and a refusal that differs by one meaningful condition: actor, ownership, state or required evidence. Check the stored result and visibility after each action. Hiding a button alone is insufficient evidence that the action is refused.
Protect access through relationships as well as direct reads. A maintenance reference must not disclose another reporter’s title, work notes or resolution to someone without access to both tickets. Linking does not grant access.
Separate approval
Permit separate equipment approval; refuse self-approval even when the requester also holds the reviewer role.
Complete approval chain
Permit delivery after every required approval; refuse delivery while Finance is missing and confirm no delivery fact was written.
Assignment authority
Permit HR to reassign unfinished work; refuse unauthorised reassignment and completion by the former assignee.
Completion authority
Permit the current assignee to complete; refuse completion merely because the actor is HR or an ordinary teammate.
One replacement
Permit a submitter’s one linked replacement; refuse a second branch, approval/payment on the returned original and copied old approvals.
Protected history
Confirm completed approval, payment and delivery facts stay protected; originals remain available only under existing visibility permissions.