The access problem you don't have until you do
In a one-person shop, permissions are a non-issue: you are the owner, the dispatcher, the tech, and the bookkeeper, and you should see everything because everything is yours. The trouble starts the moment the crew grows past you. Now there's a tech who needs their jobs for the day but has no business changing the company's pricing. A dispatcher who runs the board but shouldn't be editing billing. An office admin who handles customers and invoices but never touches the dispatch logic. "Everyone sees everything" stops being convenient and starts being a way for an honest person to make an expensive mistake — or for a departing one to walk out with more than they should.
The instinct is often to ignore it ("my people are trustworthy") or to over-lock it ("nobody can do anything without me"), and both are wrong. Trust isn't the issue; blast radius is. A tech who can accidentally reopen a closed job, a viewer who can quietly change a customer's address, an account that still has full access three months after the person left — none of these require bad intent to cause real damage. The goal of roles isn't suspicion. It's making sure each person's mistakes can only land inside the part of the operation they're responsible for, and that the door closes cleanly when someone leaves.
Roles beat per-person tinkering
The wrong way to do access is one person at a time — granting Maria this, denying Tom that, until you've built a tangle nobody can audit and every new hire is a fresh round of guesswork. The right way is roles: a small set of named access levels that map to the jobs people actually do, so onboarding a new dispatcher is "make them a dispatcher," not an afternoon of toggles. The role carries the permissions; the person just gets the role.
A good role set is small enough to hold in your head and shaped like your actual org chart. The owner runs the business. An admin manages settings and the team without being the single owner. A dispatcher lives on the board and the jobs. A technician sees and updates their own work. A viewer — a bookkeeper, a partner, a manager — can look without touching. Five levels covers almost every field shop, because almost every field shop has those five kinds of people. When the role names match the roles your people already have, access stops being a configuration problem and becomes obvious.
How Hosting Field's roles and isolation work
Hosting Field ships five roles — owner, admin, dispatcher, technician, and viewer — and they're not cosmetic labels; they gate what each person can actually do. The most important place that shows up is the job workflow: the seven-state job lifecycle has role-gated transitions, so who's allowed to move a job from one state to the next depends on their role. A tech advancing their own job through the day is normal; the actions that should belong to the office stay with the office. The workflow stays honest because the permission to change it is part of the role, not an open door for anyone logged in.
Underneath the roles sits the harder guarantee: per-organization data isolation enforced by row-level security on every record. This is the part that's easy to get wrong and dangerous when you do — it means a member of one organization simply cannot read another organization's data, because the database itself refuses, not because a screen happens to hide it. Roles decide what you can do within your shop's data; row-level security decides that your shop's data is yours alone. And the lifecycle of access is managed where it should be: you invite members, change a role when someone's job changes, and remove access entirely when they leave — so the departing tech's account closes the same day, not three forgotten months later.
The honest boundary: these are five practical, role-based access levels with hard per-org isolation — not a fully custom, build-your-own-permission-matrix system where you hand-pick thirty individual capabilities per user. You assign one of five roles, not a bespoke permission set. For the overwhelming majority of field shops that's exactly right — the five roles are your org chart, and a simple system people actually understand beats a granular one nobody configures correctly. If your structure genuinely doesn't fit five roles, that's worth knowing up front. What Hosting Field guarantees is the thing that actually protects you: each person works inside their role, and no organization can ever see another's data.
Setting it up so it stays clean
- Assign the lowest role that lets someone do their job. A bookkeeper who only needs to see the numbers is a viewer, not an admin. Start narrow; it's easy to promote someone who turns out to need more and painful to discover too late that someone had access they never needed.
- Make role changes part of the moment, not a someday. When a tech becomes a lead, change the role then. When someone leaves, remove access that day — the offboarding step people forget is the dangerous one, because a live account with nobody behind it is pure downside.
- Use separate organizations for genuinely separate operations. If you run distinct businesses or branches whose data should never mix, that's what per-org isolation and running multiple organizations is for — not one big org with people you hope stay in their lane.
What to measure
- Active accounts versus active people. The two numbers should match. Every account belonging to someone who left or a role nobody fills is access with no owner — the cleanest thing a quarterly review catches and the easiest to fix.
- Mis-permission incidents. How often someone hits "I can't do the thing my job needs" or, worse, "I changed something I shouldn't have been able to touch." A handful of the first means a role's too tight; any of the second means one's too loose.
- Time to revoke on departure. How long between someone leaving and their access being gone. The right answer is same-day; anything longer is a window where a former member can still reach your customers and your jobs.
When the crew was just you, seeing everything was the whole point. As it grows, that same openness quietly turns into the way a good employee makes a costly mistake and a former one keeps a key. Roles fix it not by distrusting your people but by shrinking the blast radius of any single one — each person works inside the part of the operation that's theirs, and the database makes sure no other shop's data is ever reachable at all. Hosting Field's five roles, role-gated job transitions, and per-org row-level isolation give you that without a permissions degree. Give each person exactly the access their job needs, close the door cleanly when they go, and access stops being a worry and goes back to being invisible — which is exactly what good access should be.