A shared spreadsheet often relies on people knowing which cells they should leave alone. Once that workflow becomes a business application, those informal boundaries need to become clear rules. A salesperson may need to update an opportunity without changing an approved price. A branch manager may need local reports without seeing every branch.
Planning user roles and permissions means deciding who can perform each action, on which records, and under which conditions. This guide helps business owners and project leads prepare those decisions before development starts. The examples describe an illustrative service business, not a customer implementation.
Start with actions and records
Listing job titles is a useful beginning, but it does not define access. Two people called managers may have different responsibilities. One approves work; another manages schedules. Start with the workflow and write down the actions that change its outcome.
For a service request, those actions might include creating a request, assigning a colleague, editing a quote, approving work, closing the request and exporting its history. Then name the records each person needs: their own requests, their team's requests, one branch or the whole business.
Keep viewing and changing separate. Someone who can view an approved quote does not necessarily need permission to change it. Likewise, seeing a report on screen should not automatically grant permission to download the underlying customer list.
Create a small permissions matrix
A permissions matrix makes the proposed rules reviewable without asking everyone to interpret a technical specification. Use business actions as rows and a small set of roles as columns. Add record boundaries wherever a simple yes or no would hide an important condition.
| Action | Request coordinator | Branch manager | System administrator |
|---|---|---|---|
| View service requests | Assigned branch | Managed branch | Only if separately granted |
| Edit a draft quote | Assigned requests | Managed branch | Only if separately granted |
| Approve a quote | No | Managed branch, within agreed limit | No by default |
| Export customer records | No | Separately approved scope | No by default |
| Create and disable accounts | No | No | Yes |
This is a discussion example, not a ready-made policy. Your business must define approval limits and decide whether those responsibilities belong together. A technical administrator may need to manage accounts without receiving routine authority to approve commercial work.
Define record boundaries explicitly
A role answers what someone can do. A record boundary answers where that permission applies. Write down both. A rule such as "managers can edit requests" remains incomplete until you define whether it means their branch, their department or every request.
Consider changes over time. If a coordinator moves to another branch, should they retain access to old requests? If a customer is reassigned, who can view the previous correspondence? Avoid leaving those decisions to whoever implements the first screen.
For software serving multiple client companies, define company boundaries separately from internal roles. A user from one company must not gain access to another company's records by changing a link, guessing an identifier or requesting an export. Include related files, search results and background reports in that boundary.
Treat approval as a workflow decision
Approval often depends on the state of a record. A draft can be edited freely by its owner, while an approved request may require a revision and another approval. Decide which fields become restricted and what should happen when someone needs a correction.
Write one concrete example: a coordinator submits a quote; a manager reviews it; changing the agreed scope after approval returns the quote to review. Specify whether the original approval remains visible and who receives the next task.
Also decide whether someone can approve their own work. If a small team needs exceptions, define who authorises them and how they are recorded. An undocumented workaround can quickly become the normal process. For broader workflow design, see our business workflow automation guide.
Plan account changes and temporary access
Access planning includes joining, changing responsibilities and leaving. Name who requests an account, who approves its role and who disables it. Shared accounts make responsibility harder to establish, so plan individual accounts for people who perform business actions.
Temporary access needs an end condition. A colleague covering leave may need another branch for a week; a support provider may need limited access while investigating an issue. Record the reason, approver and expiry, and define how access ends. Do not assume that changing a password removes existing sessions or other credentials.
Decide how account suspension affects active sessions, API credentials, scheduled exports and unfinished assignments. The exact implementation depends on the application, but the required business outcome should be part of the brief.
Make important changes traceable
Identify events that need a history: role assignments, approvals, exports, changes to important settings and corrections to approved records. Define the context needed to investigate an event, such as the actor, action, record and time.
An activity history helps explain what happened; it does not replace access restrictions. Avoid placing passwords, secret keys or unnecessary personal information in logs. Decide who can review the history and how long it should remain available according to the business requirements.
Where access affects sensitive workflows, review the plan with the people responsible for that information. Developers can implement rules, but the business owner must decide who is entitled to act.
Test denied actions as well as allowed actions
Review permissions with representative accounts and records before release. Checking that a manager can approve a request proves only one path. You also need evidence that a coordinator cannot perform that approval through a direct request, an old link or another interface.
- Try opening a record from another branch or client company.
- Try changing an approved record through the normal screen and a direct request.
- Confirm that exports and downloaded files respect the same boundaries.
- Remove a role and check what access remains in an existing session.
- Check that a background job does not send data to someone who has lost access.
- Confirm that important permitted actions appear in the activity history.
Turn each relevant check into an observable requirement. Our MVP acceptance criteria examples show how to connect a requirement with review evidence.
Questions to settle before development
How many roles should the first release have?
Use the smallest set that represents real differences in responsibility. Start with common workflows, then add a role only when an existing one would grant too much or prevent necessary work. Avoid building a complicated permissions editor before you know who will maintain it.
Can we change permissions after launch?
Yes, but access changes can affect reports, assignments and approvals already in progress. Keep a current matrix, review the impact of each change and test the affected workflows before applying it broadly.
Should every administrator see all business data?
Make that an explicit decision. Account management, technical support and commercial authority are different responsibilities. Grant the access each responsibility requires and document any emergency access process.
Bring a permissions brief to the project
Prepare a list of roles, actions, record boundaries, approval rules and account lifecycle decisions. Add two or three awkward examples from the current workflow. Those examples often reveal gaps that a generic feature list misses.
If you are replacing a spreadsheet, use this alongside our spreadsheet migration plan. To scope permissions within a new application, explore RuhaniSoft custom software development or discuss your workflow with our team.