Who Can See What: Permissions in a Small Business System

Most nine-person shops don’t have a permissions problem. They have a permissions absence. Everything lives on one shared drive, one shared inbox, one shared login, and everyone can see everything because nobody ever had a reason to stop them. That works fine right up until it doesn’t: a staff member leaves on bad terms, a customer disputes a payment and three people give three different answers, or an owner realises the office coordinator who books appointments can also see exactly what every job billed. None of that is malice. It’s just a business that grew past the point where “everyone sees everything” was harmless.

This guide walks through the permission model actually built for a fire-safety inspection contractor, why it landed on three roles instead of nine fine-grained ones, and how to decide what your own business actually needs before you buy or build anything.

The three roles that came out of a real build

The fire-safety engagement settled on three distinct roles, each mapped to how the business already worked, not to a generic software template:

• Admin. Sees everything, including money: invoices, payments, outstanding balances, the full client history. This role fits the owner and anyone who runs the business end to end.
• Coordinator (office role). Handles intake, scheduling, and quoting. Explicitly and structurally blocked from ever seeing invoices or payments, enforced at the permission layer, not just hidden behind a menu they could still reach if they knew the address. A coordinator can book a job, quote a job, and schedule a technician, but cannot see what the job actually billed or whether the customer paid.
• Technician (mobile-only). Sees only their own assigned jobs. The moment a job is invoiced, the technician is locked out of that job’s data entirely. A technician who finished the work has no ongoing view into what the office billed the customer for it.

That’s the whole model. No fourth role, no fifteen granular checkboxes for “can view but not edit” on every field. The design principle behind it, stated directly by the team that built it, was to trust the small staff and use role structure rather than heavy per-action permission ceremony. Three roles, hard boundaries, nothing fussier than that.

Why “hidden” and “restricted” are not the same thing

This is the distinction that actually matters, and it’s the one most off-the-shelf tools get wrong by default. A lot of software “restricts” access by simply not showing a button. The underlying data is still reachable if someone knows, or guesses, the right web address, because nothing on the server actually checked who was asking.

On the fire-safety build, the permission boundaries were verified with direct-API denial testing: a coordinator’s login was used to directly request invoice data through the same channel the software itself uses, bypassing the interface entirely. The result was a flat rejection (an HTTP 403 “forbidden” response) with no data returned in the response at all, not just a blank screen with the data quietly present underneath. That’s the difference between a permission model and a permission suggestion. If your current system only hides a menu item, you don’t have access control. You have a slightly awkward interface that a curious or motivated person can see straight through.

If you’re evaluating a system for your own shop, ask the vendor this directly: if I log in as the more restricted role and request the restricted data by its direct web address, not through a button, what happens? “Nothing comes back” is the right answer. “I’m not sure” is not.

Why the coordinator role exists at all

It would have been simpler to build two roles: admin and technician. The coordinator role exists because a real office job in a small trades business is not the same job as running the business. Someone needs to answer the phone, book the job, and send the quote, without needing to know what every past job billed or whether a specific customer is behind on payment.

That split matters for reasons that have nothing to do with distrust. An office coordinator who can see every client’s outstanding balance is one uncomfortable conversation away from a customer relationship problem, because customers ask staff things they’d never ask the owner directly, and a coordinator without money visibility has an honest, simple answer: “I don’t have that, let me get the owner.” A coordinator who can see it either has to improvise an answer on the spot or awkwardly claim not to know something they can plainly see on their own screen.

There’s also a much more ordinary reason: fewer things to accidentally break. A coordinator role that can’t touch invoices can’t accidentally edit or delete one while trying to reschedule a job. Narrow roles aren’t just about who you don’t trust. They’re about reducing the number of ways an honest mistake can turn into a real problem.

Why the technician gets locked out at invoicing, not before

The technician role is mobile-only and scoped to a technician’s own assigned jobs, which is an easy design choice to justify: a technician has no operational reason to browse someone else’s job history. The less obvious choice is what happens after the technician finishes the work.

On this build, a technician loses visibility into a job’s data the moment it’s invoiced. Before that point, they can see and update their own job (arrival and departure, checklist, materials, work performed, photo, signature). After invoicing, that job moves into the office and accounting side of the process, and the technician’s access to it ends.

This isn’t a trust statement about technicians. It’s a scope statement. A technician’s job is to do the work and record that it was done. What the office does with that record afterward (pricing, invoicing, collections) is a different job, done by a different role, and there’s no operational reason for a technician’s login to carry that visibility forward once their part of the work is finished.

Deciding what your own business actually needs

Before you buy or build anything, write down, honestly, who currently sees what, and whether that was a decision or an accident. A short exercise that works for a business this size:

• List your roles by job, not by name. Not “what can Dana see” but “what does the person who answers the phone need to see, regardless of who’s doing that job this year.”
• Separate “does the work” from “bills the work.” These are almost always different concerns even when the same person does both today. A role model built around that split survives staff turnover better than one built around a specific person’s current trustworthiness.
• Ask what happens after someone leaves. If a coordinator or technician left tomorrow, would their access disappear cleanly, or is company data spread across logins, shared drives, and personal devices in a way nobody can fully revoke?
• Push back on anything that only hides a button. If a vendor’s answer to “can they see this” is “well, they wouldn’t know where to look,” that is not an access control, it’s a hope.

None of this requires building something complicated. The fire-safety engagement proves the opposite: three roles, cleanly enforced, covered a real multi-person business end to end, without a single per-field permission checkbox anywhere in sight. The goal isn’t more roles. It’s the fewest roles that match how the work actually splits, each one backed by a real boundary the software enforces whether or not anyone remembers to check.