Agree Access Permissions Before System Handover

Set the handover boundary

Suggested workflow practice: use this guide after the intended custom-system release is scoped and accepted, but before routine users receive access. Its deliverable is a permission matrix: a decision sheet stating which job role may view, change or export each agreed record group. It does not reopen fields, workflow stages, reports or integrations. If a requested permission needs a new screen, data source or workflow rule, record it as a separate scope decision.

Suggested workflow practice: bring the dated scope, accepted workflow description, agreed record groups, named business approver and implementation contact. Start with roles, not people. A role represents repeatable work, such as operations coordinator, field colleague, finance reviewer or owner. People can later be assigned to roles without rewriting each permission decision.

Suggested workflow practice: keep authentication and authorization separate. Being able to sign in does not give a person a right to open a record, alter a status or export a list. The matrix records authorization decisions only. Do not include passwords, login links, real customer records or personal credentials.

• Confirm accepted release boundary
• Name business approval owner
• List intended job roles
• Exclude personal credentials

Build the permission matrix

Suggested workflow practice: begin with record groups rather than a vague label such as staff access. A record group is information with a shared business purpose: job records, customer contacts, payment status, attachments, user settings or audit history. Split a group if its parts need different handling. A coordinator may update job status, for example, without being allowed to change a payment amount.

Suggested workflow practice: create a row for every role-and-record-group combination. Add View, Change and Export columns. Mark every cell Allow, Deny or Needs decision; do not leave blanks. Add a short reason connected to the role’s work. Where needed, state a condition such as view assigned jobs only or change draft records only. Write the condition in business language before it is translated into a system rule.

Suggested workflow practice: use deny by default and grant only the minimum action needed for the named role. Viewing does not automatically mean export is needed, and viewing payment information does not automatically mean changing it is needed. A recorded denial makes a boundary visible and testable.

Suggested workflow practice: treat export separately from viewing. State what can be exported, which role needs it, the operational reason and whether an additional approval is needed. A download feature is not automatically appropriate merely because someone can view the underlying information.

• Group records by purpose
• Mark every action explicitly
• Write conditional access rules
• Separate export decisions

Decide access exceptions

Suggested workflow practice: make temporary access specific and expiring. Record the temporary role, record group, actions, reason, approver, start point and expiry event or date. Also record whether expiry removes access, restores a prior role or requires a new written decision. Access with no owner or end condition can become an unnoticed permanent privilege.

Suggested workflow practice: use a simple decision path for uncertain requests. Ask whether the named role needs the action for an accepted routine task. If yes, grant the smallest applicable access and record the reason. If no, deny it. If the work is legitimate but unusual, use temporary access with an approver and expiry. If it introduces a new record group, action or workflow dependency, hold it for a scope decision.

Suggested workflow practice: write explicit denials for sensitive combinations even when nobody has requested them. Examples may include a field role exporting a full customer list, a general user changing other users’ roles, or an operational role changing audit history. The exact decisions depend on the business context.

Suggested workflow practice: name one business approver for permission changes and one route for requests. The approver decides whether the role needs access; the developer or administrator applies the approved decision. This helps stop an informal chat request becoming an undocumented change. It does not create a legal or compliance process.

• Set temporary access expiry
• Record explicit denied combinations
• Name change approver
• Escalate new-scope requests

Review a fictional example

Fictional example: Cedar Lane Services has accepted a small internal job system. Its roles are Operations Coordinator, Field Technician, Finance Reviewer and Owner. Record groups are Job Details, Customer Contacts, Payment Status, Attachments, User Settings and Audit History. The team writes the matrix in a meeting; no live account changes during this review.

Suggested workflow practice: the Operations Coordinator may view and change Job Details, and view Customer Contacts and Payment Status. The role cannot export the customer list, change User Settings or alter Audit History. A Field Technician may view assigned Job Details and selected contact instructions, update completion status and upload an agreed attachment. The role cannot browse all jobs, view payment status or export records.

Suggested workflow practice: Finance Reviewer may view Payment Status and export an agreed payment report, but cannot change job assignments. The Owner may view agreed operational groups, while User Settings access is decided separately. If Finance Reviewer covers operations for two weeks, record temporary view access to Job Details, the cover reason, approver and exact expiry. Test the expected denial after expiry.

This fictional example illustrates different rights across record groups and why permissions should not be copied wholesale from a colleague. It does not prescribe roles for another business or prove that a system is secure.

• Label fictional examples clearly
• Test assigned-record boundaries
• Confirm temporary expiry behavior
• Retain approval reference

Turn decisions into checks

Suggested workflow practice: before access is issued, give the approved matrix to the developer or administrator as an implementation input. Ask them to map every Allow, Deny and condition to an enforcement point. Permission checks should occur when each request reaches the system, not only through hidden menu items. A hidden control can improve usability but does not show that a direct request will be refused.

Suggested workflow practice: create developer-owned test cases from the matrix. For each material row, test a permitted action and a prohibited action. For assigned-record rules, test an assigned and an unassigned record. For export, test a permitted export and an attempt by a non-export role. For temporary access, test before expiry and the expected denial after expiry. Record role, record type, requested action, expected result, actual result, tester and date.

Suggested workflow practice: request useful authorization logging where the agreed system supports it. Sensitive successful or refused actions should be traceable to an account or role. Decide who may review those records and whether audit history remains read-only for routine roles. A log alone does not establish that every issue will be found.

Suggested workflow practice: conduct a short handover review with the business approver, access administrator and implementation contact. Resolve every Needs decision, assign people only after the role matrix is approved, and retain the final matrix with the release record. Revisit it when responsibilities or record groups change. Outcomes are not promised.

• Map rules to enforcement
• Test allows and denials
• Verify export restrictions
• Store final matrix safely

Use the reusable sheet

Suggested workflow practice: include these fields in each matrix row: release reference, role, record group, action, scope condition, Allow, Deny or Needs decision, business reason, approving person, decision date, temporary start and expiry where applicable, implementation status and test reference. Keep it concise, but specific enough that another person need not guess what admin access meant.

Suggested workflow practice: read rows aloud by role during handover. Ask what work the role performs, which record group is necessary, whether viewing is enough, whether export creates a separate need, what the role must never do, who approves exceptions and what ends temporary access. These questions expose missing decisions without becoming a new system-design exercise.

Suggested workflow practice: revisit the sheet when a role changes, a record group is added, a contractor or cover arrangement is proposed, or a user requests broader access. Do not grant access first and document later. If urgent continuity work requires temporary access, record the smallest action, named approval and expiry at the time, then review it once normal work resumes.

• Use one row per decision
• Attach approval evidence
• Review changed responsibilities
• Remove expired access