Permissions that follow the job, not the job title

Most software gives you a ladder: viewer, staff, manager, admin. If you want your lead mechanic to write quotes, you move them up a rung, and with that rung comes everything else on it: billing settings, user management, whatever the software decided a manager should have. So shops either over-grant, or they keep everything with the owner and the owner becomes the bottleneck.

Service is built around named permissions instead of rungs. Each one is named for something a person does in the shop: close a visit, build a checklist template, write a quote, record a payment, approve someone else's hours. The question an owner actually asks is "who can bill a job?", and a permission named for that act can answer it.

Today those permissions come as sets, from the role each person holds in your erp.io workspace. The next step, handing one extra permission to one person without changing their role, is designed and not yet on screen.

Your erp.io workspace has four roles: viewer, operator, workspace admin and super admin. Service maps each one to a set of defaults and never raises it. A viewer can look at sites, jobs and the schedule, and nothing else, because every other act is a write. An operator, the usual seat for a mechanic, gets the crew defaults: see the work, close a visit, fill in checklists and clock their own time. A workspace admin or super admin gets all fifteen.

That has a practical consequence you should plan for. A mechanic on an operator seat today cannot schedule work, write a quote, raise an invoice, build a checklist template or approve anyone's hours. If your service manager needs to do those things, give them the workspace admin role for now. Service also defines lead and manager defaults, for example a lead who can schedule and approve the team's time, and a manager who can also quote, invoice and build checklists. Those are reached by grants, which arrive with the grants screen.

Unknown roles fail closed. If a sign-in ever arrives with a role Service does not recognize, it is treated as a viewer, the least privileged role, not the most convenient one. Someone who is under-granted asks for more; someone who is over-granted rarely notices.

A few rules hold whatever the role, and they are written into the code rather than left to settings. Nobody can approve their own timesheet. A viewer seat can never be given a write, so a part-time bookkeeper on a viewer seat can, once grants arrive, be allowed to read submissions or run an export but never to change anything.

Three acts stay with administrators even when grants exist. Publishing a checklist to the public internet is one, because building a form for the bench and putting an intake form in front of strangers are different risks. Changing what other people may do is another. The third is recording a payment, because saying money arrived is the one act in Service with no work behind it to check against. An operator could be granted quoting and invoicing, but not that.

Reading is not editing. Someone who can see every checklist in the workspace still cannot change, submit or discard anyone else's.

A typical small shop sets up like this. The owner and the service manager hold workspace admin seats, so they can schedule, quote, bill, approve hours and record payments. Mechanics hold operator seats: they see the week, open the visits assigned to them, fill in the required checklist, close the visit and clock their time. Anyone who only needs to look, such as a bookkeeper checking what was billed, has a viewer seat.

The owner then does not need to be the bottleneck for checklist changes or quotes, as long as the service manager has an admin seat. When the grants screen ships, you will be able to narrow that: a lead mechanic who can build the tune-up template and approve the bench's hours without being a workspace admin.

People, seats and roles themselves are managed in your erp.io workspace, not in Service. Extra users are $20 each on every plan, and nothing inside Service is gated by plan.