Who can change a price? Plan your business app permissions

By Noe Guerrero III

A business app needs more than an “admin” account and a “staff” account. Before development, write down who can perform each important action, which records they can use and what should happen when permission is missing. That small document gives the owner and developer something concrete to agree on.

Start with a decision that could disrupt an ordinary workday: changing a price, downloading customer details or moving a job to another technician. If the answer is “the right people can do that,” the brief isn't finished yet.

Describe the work before naming the roles

A role name tells only part of the story. “Technician” might mean someone who can see every repair request, or someone who can see only their assigned jobs. Those are different requirements even if the account menu looks identical.

List actions using plain verbs: view, create, edit, approve, export and archive. Split them when the business treats them differently. Reading a customer's appointment doesn't automatically answer whether that person should download the whole customer list.

Then add the boundary. Is the permission for one assigned job, one branch or the entire business? Write any required condition beside it, such as “appointment is still a draft.” Leave a question visibly unresolved instead of quietly treating it as permission.

OWASP's authorization guidance distinguishes signing in from permission to act. It recommends minimum necessary privileges, denial by default and permission checks on every request. Hiding a button alone doesn't enforce the rule; the server must check it too.

The business owner supplies the operational decisions. The developer chooses and implements an appropriate access-control design. A short planning table helps that conversation without pretending to be the implementation.

Work through one hypothetical repair shop

Imagine a small appliance repair shop in McAllen planning an internal scheduling app. This shop and its rules are fictional. It has a front desk, technicians and a manager; the proposed first release serves one branch.

Here is a starting permission matrix for that example. Anything outside these rows still needs a decision before it's included in the release.

Notice the gaps this exposes. The front desk can create a draft, but who confirms it? Can a manager reopen a completed job? What happens when the assigned technician is absent? Those are product questions to resolve with the shop, not reasons to grant everyone unrestricted access.

Keep the first release small enough to explain. If a proposed exception needs a paragraph, give it its own rule and example. A temporary replacement technician, for instance, might receive a documented reassignment rather than access to every job.

For each row, also name the person who can approve a policy change. Otherwise a convenience request during a busy afternoon can quietly become a permanent permission nobody remembers agreeing to.

Separate approval from doing the work

A team may want someone to request a price change without letting them apply it. Write those as separate actions. Decide who reviews the request, whether the requester can approve their own proposal and when the approved price takes effect.

Use one ordinary example to check the wording: a technician notices the listed service price is outdated. Can they send a proposed correction? Who sees it? What price should the front desk quote while the request is waiting? The brief should let staff answer those questions without reading code.

Don't add an approval workflow merely because it sounds sophisticated. If only the manager changes the price directly, say that. The useful result is an agreed process the business can operate, with the remaining decisions clearly marked.

This table can accompany the customer journey, data fields and acceptance criteria in an app development project brief. It explains a specific part of the scope instead of leaving “user management” as an undefined line item.

Ask for evidence of the denied cases

A demonstration with a manager account won't show whether a technician is correctly restricted. Review allowed actions and expected denials using separate test accounts and invented records in an agreed test environment.

OWASP's authorization testing automation guide describes a matrix connecting features, roles and, where needed, business data. Its approach turns those combinations into integration tests. Ask the developer how the agreed rules will be represented in repeatable checks.

For the fictional shop, the owner could request these acceptance scenarios:

• The front desk can save a draft appointment but cannot change the price list.

• A technician can read service notes for an assigned job, but cannot read service notes for a job assigned to someone else.

• A technician can complete an in-progress assigned job, but cannot complete an unstarted job under this proposed rule.

• A technician cannot export the customer list, including through a direct request to the export service.

• After a test job is reassigned, the previous technician cannot read its service notes or mark it complete.

Have the developer record the account role, relevant assignment or record state, attempted action, expected result and observed result. For a denied write, check that the underlying record stayed unchanged. Keep failures and unresolved cases in the handover; a screenshot of a hidden menu isn't the same evidence.

Keep the rules with the next release

New exports, branches and approval steps deserve another look at this document. OWASP's authorization regression testing guidance covers checking access boundaries as software changes, including access to another user's records and higher-privilege actions.

Put a review date, policy owner and release reference on the matrix. When a workflow changes, update its rule, example and test together. Ask who updates a person's access when their responsibilities change, too.

A permission matrix doesn't establish that an app is secure. It makes the business's intended boundaries reviewable, so development and testing have a clear target. Begin with the few actions that matter most, settle their scope and ask to see both the allowed and denied outcomes.