Esta publicación todavía no se ha traducido al español. A continuación se muestra la versión en inglés.

Who Can See What: Roles and Permissions for a Growing Service Business

The day your crew outgrows "everyone can see everything" - and why real permissions need a server.

Por Toolberry Team18 de julio de 20268 min de lectura

Actualizado el 18 de julio de 2026

The day your crew outgrows "everyone can see everything" - and why real permissions need a server.

Published July 2026.

The short answer

Once you have staff, somebody has to decide who can see pricing and margins, who can change a job, who can see the whole customer book, and who keeps access after they leave. That's roles and permissions. Real permissions can't be enforced on a device the user controls - they need a server that checks every action against an identity. ToolBerry Free has no roles, by design - it's built for one operator, or a two- or three-person crew who share everything. Roles are exactly what ToolBerry Pro is being built for.

The day permissions start to matter

Renata spent four years cleaning houses solo before she started hiring. It didn't take much to change everything: a second cleaner, a third, her cousin on the schedule and phones, a part-timer for busy weeks. Five people - and the app that had been perfect for one person was suddenly a problem.

When it was just her, having the whole business on one phone was the point. At five people, the same setup meant:

The newest cleaner can see exactly what every client pays - and told one she thought the price was high.
Her cousin deleted a client with four years of notes and lockbox codes, thinking it was a duplicate.
A weekend part-timer has every client's address and gate code on her personal phone - and she cleans for two other companies too.
The cleaner who quit in March still has the app installed, with the whole book in it.

None of this is because Renata hired badly. It's that somewhere between two people and five, "everyone can see everything" stopped being a reasonable default - and nothing in her software noticed.

Here's the part that surprises most owners: roles don't become a real question at fifty employees, or even twenty. They start mattering at about four or five - the moment the people using the app are no longer just you and someone you'd hand your bank card. The stakes keep climbing as you grow, but the line you cross is early.

What roles and permissions actually mean

Two words get used interchangeably and shouldn't be:

Authentication is proving who you are. The front door. A login.
Authorization is what you're allowed to do once you're inside. Which rooms you can enter, and what you can touch in them.

A role bundles authorization into something a human can reason about: tech, dispatcher, estimator, office manager, owner. Permissions underneath can be coarse (can you open Invoices at all?) or fine (can you see the cost column on the invoice you're allowed to open?).

You need both. A login with no authorization behind it just means everyone is identified while still seeing everything.

The four questions every growing operation has to answer

Who can see money? Pricing, margins, what you charge, what you pay. This is usually the first line owners want drawn.
Who can change the record? Editing and deleting jobs, customers, and history - and whether there's any trace of who did it.
Who can see the whole book? The entire customer list, or just today's route. This is the question that matters most the day someone leaves for a competitor.
What happens when someone leaves? Access has to be revocable from somewhere central, immediately, without collecting a phone.

Worth saying plainly: this isn't about assuming your crew are thieves. Most insider incidents are ordinary mistakes. Ponemon Institute's 2025 Cost of Insider Risks research found negligent employees were the root cause of 53% of insider incidents, against 27% that were malicious. Permissions mostly protect good people from expensive accidents - and protect you from the one bad exit you didn't see coming.

Why permissions genuinely need a backend

Here's the part most software marketing skips.

On a device you own, you control everything on it. A local-only app can hide the cost column - grey it out, leave it off the screen - but the data is still sitting on that device, and the check that hides it runs on hardware the user controls. Anyone determined enough can get underneath it. A hidden field is a curtain, not a wall.

Real enforcement has to live somewhere the user can't reach around: a server that holds identity and checks every single request against it. "Is this person allowed to see margins?" has to be answered by a machine you control, not the one in their pocket. That's a trust boundary, not a feature toggle - and it's why authentication and permissions can't be done offline-only.

Revocation makes it obvious. You cannot un-send data that's already on someone's phone. Taking access away requires a gatekeeper that was standing there the whole time.

Where ToolBerry stands today - honestly

ToolBerry Free has no roles, and we're not going to pretend otherwise. Free is built for a single operator, or a two- or three-person crew who trust each other with everything. Whoever has the device has the data. That's not a gap we're hiding - it's a direct consequence of the same architecture that makes Free free, offline, and account-less. For one person and a truck, it's exactly right.

Roles are what ToolBerry Pro add to the table, because permissions are one of the capabilities that need a backend anyway - the same line that separates Free from Pro across sync, booking, payments, and notifications. (That story is in Free vs Pro.)

If you're running a real team, contact us - we can help you setup your roles around how your business actually works than guess at it from a whiteboard.

What to look for when you evaluate any app

Six questions worth asking on a demo, whoever you're buying from:

Is enforcement server-side? Ask directly: "if a tech gets underneath the app on their own phone, can they see costs?" If the hiding happens only in the app, it's cosmetic.
Do the roles match a trade? "Admin" and "User" is not a role model. Tech, dispatcher, estimator, office, owner is.
Can you control fields, not just screens? Letting someone open a job without seeing the margin is the single most common real need.
Is there an audit trail? Who changed the price, and when. Without it, permissions are half a system.
Can you offboard in one action? Revoked centrally, everywhere, without chasing a device.
Does the field app still work offline under a restricted role? Permissions shouldn't cost you the reliability you bought the app for.

The honest tradeoffs

Roles add overhead. Someone has to own the permissions model and keep it current as people join and move around. That's real work, and a two-person crew who trust each other completely doesn't need it yet - but the inflection comes around the fourth or fifth person, not the fortieth.

Too granular and nobody maintains it. Start with three roles, not eleven. A permission model no one updates is worse than none, because you'll trust it when you shouldn't.

Offline and permissions genuinely fight each other. Cached permissions can go stale; a disconnected device can't be revoked in real time. Any honest vendor will describe tradeoffs here rather than claim it's solved.

Have a question?

We'd genuinely like input from people running real crews. What are the three roles in your business, and what's the one thing you'd never let a field user see? Tell us at contact@toolberry.net.

ToolBerry Free: free forever for solo operators. Pro: for teams that outgrow a single device.

For the Technically Curious

The rule that governs all of this is old and unglamorous: never trust the client.

Any authorization decision that executes on the user's device is advisory. They control the process, the storage, and the network stack. You can obfuscate it and raise the effort, but you can't make it a guarantee. So the boundary has to be server-side: every request arrives carrying an identity (a token or session), the server evaluates policy against that identity, and returns only what the role permits.

Which leads to the rule that actually matters: filter at the source, don't hide in the UI. If a tech's device receives the whole customer book and the app merely declines to render it, you haven't built a permission - you've built a suggestion sitting in local storage.

That's what makes offline plus RBAC genuinely hard, and it's worth being precise about why:

Stale permissions. A device that's been offline for two days is enforcing a role you may have changed yesterday.
Revocation lag. You can't reach a disconnected device to take access away. The best you can do is expire cached credentials and refuse to sync.
Untrusted writes. Work created offline can't be taken at face value on arrival. Every queued write has to be re-validated server-side at sync time against what that role was allowed to do - the device's word isn't proof.

The move that resolves most of this in a local-first system is scoping what syncs down at all. Rather than shipping the full dataset to every device and hiding parts of it, a role determines what a device ever receives - a tech's phone holds today's route and those customers, not nine years of the whole book. The strongest permission isn't a check. It's data that never reached the device in the first place.

That's the way we setup ToolBerry Pro: local-first reads stay fast for whatever a role is allowed to hold, sync is scoped by role, and every write gets validated server-side on the way in. The architecture underneath is the same one described in Why ToolBerry Is Offline-First - with a server added exactly where trust requires one.