Role and permission matrix template for a new business app

Developers build screens quickly, but they cannot know that a branch clerk may raise a purchase request and never approve one. Nobody told them. So the rules get invented halfway through coding. The owner finds out during acceptance testing, when the storekeeper approves a purchase order that a manager should release, and the developers say the specification never mentioned it.

A matrix prevents that. It is a spreadsheet filled in before the build, with each cell stating exactly what one role may do on one screen.

Later it doubles as the test script. A tester logs in as a storekeeper and tries every cell in that column, noting whether the screen opens, hides the button or refuses the save. Each cell passes or fails. Date every change, so anyone who disputes a rule can follow it to the meeting where the process owner approved it and the version that recorded it.

List the duties your business performs, such as counter sales, stores issue, accounts payable, plant supervision, dispatch and internal audit, and one person may hold two roles. A shared title does not mean a shared role.

Under each role, write one sentence about the job and a short RACI grid for the main approvals, so developers see who requests, who approves and who is told. Add the head count. It shows whether a rule touches three people or three hundred, which decides how much testing the rule deserves before a whole branch relies on it.

Mark temporary roles, such as a stocktake team or an external auditor with a read only login, with an end date. Expired logins are a classic audit finding.

Down the rows, list each screen: customer master, quotation, purchase order, goods receipt note, sales invoice, payment run, user admin and audit log. Across the columns, list the actions of view, create, edit, cancel, approve, print and export, so every screen has seven questions to answer for every role.

In each cell write Y, N or Own. Own means the person sees only records they created or those of their branch or team, and that cell starts more arguments than any other in the matrix. Settle it early and write down who decides.

Use a notes column for the odd cases. A supervisor edits an invoice only before posting, a manager cancels only within the same working day, and a clerk reprints only with a reason code.

Approval rules need limits. Write the amount ceiling for each approving role and say what happens above it: a second approver, or escalation to a named role. Take the limits from your written delegation of authority and apply maker checker: whoever raises a voucher never releases it. Auditors call this segregation of duties.

Exports deserve their own column. A clerk who can view ten customers on screen may be able to download the whole ledger as a CSV or XLSX. Decide who exports, and from which screens. Where logins come from Active Directory or another single sign on provider, map each role to a directory group so leavers lose access when the directory removes them.

User administration is the most powerful block. Few people should reset passwords or change roles. The audit log must record every reset and every role change with the name of the administrator, the time and the account affected.

Sit with one person from each role. Ask each person for a task they do every week, then trace it through the cells one by one until you find the missing rows, duplicates and contradictions. Gaps show up fast.

Collect a sign off from the process owner and, for finance screens, from the person who answers to the auditors. Hand the signed sheet to the developers as the specification for roles, because it becomes the base of the test plan and the reference for every change request.

Put a version date at the top. Store the file where the developers and the process owners can both open it, and keep older versions so a rule can be checked against what was agreed. This week, fill in the rows for your three most sensitive screens first, usually payment run, user admin and the salary register.