Roles and permissions

Five construction roles — Admin, Sales Rep, Project Manager, Crew Leader, Worker — each carrying about thirty specific abilities across navigation, actions, customer documents, stage controls and admin.

What it is

A single permissions map defines what each role can view and do: which nav tabs appear, whether they can edit projects, pipeline cards or estimates, whether they see contracts, invoices and change orders, granular stage controls (status, dates, details, tasks, photos, issue reporting), and admin abilities like deleting, managing users, linking building plans, inviting members and seeing all crews.

Also called: who can see what · user roles · access control · stop the crew seeing prices · permissions

See it
Roles and permissions
Prepared for
Gideon Alt
1140 Ridge Line Rd · Fair Play
Shell package$28,663
Concrete & site$8,321
Doors & windows$5,548
Trim & finish$3,698
Total
$46,230
Signature
The Permissions block inside an expanded member card: five category headings with two-column checkbox grids, overridden items in accent colour. Sample data — no customer information appears here.
How it works
  1. 1ROLE_PERMISSIONS in lib/permissions.ts is the canonical map; getPermissions(role) returns a copy.
  2. 2The client uses it to hide or show controls; server routes enforce the real authorisation boundary.
  3. 3Roles come from the signed-in user's account metadata, written on onboarding for owners and by the invite-accept handler for invitees.
  4. 4Anyone with no explicit role defaults to worker — the least-privileged role.
Why we built it

The file records two real incidents. Permission overrides used to be stored in localStorage, which 'let any user grant themselves permissions via DevTools' — they were removed and the functions left as documented no-ops. And the client role used to default to admin, so 'an invitee who accidentally landed on /sign-in (instead of going through the invite-accept handshake) would see every section of the app as if they owned the tenant'; the visible effect was Danny's bug — 'I can see Sales Pipeline but it's empty'. The Project Manager row carries its own note: canViewEstimates was originally false 'but operators kept hitting my PM can't see what we sold the customer', so PMs now view estimates while still not being able to edit them.

The problem
  • Everyone who could sign in saw everything.
  • Permission overrides could be self-granted from the browser.
  • A user with no role defaulted to full access.
Sound familiar?
What you get
Pricing, contracts and invoices stay with the people who should see them.
Field roles get exactly the stage controls they need and nothing else.
A misconfigured account fails closed at the lowest privilege.
What's inside
Permissions grouped into five plain categories
Roughly thirty permissions are grouped as Navigation, Actions, Customer Documents, Stage Controls and Admin so the grid reads as decisions rather than a flat list of flags.
Plain-English explanation of every permission
An ⓘ beside the meaningful permissions opens a modal describing what it unlocks and giving a concrete example of what the person would see.
Per-person permission overrides
Tick or untick individual permissions for one person on top of their role, with anything that differs from the role shown in accent colour.
Crews only see their own work
When View All Crews is off, a user only sees projects assigned to their own crew, and the crew filter UI disappears entirely.
Unknown users get the least access, not the most
Anyone signed in without an explicit role is treated as a worker, and the UI waits for the role to load before deciding what to show.
Roles & Access — one tab, two views
Permission presets (what a role can do) and Lead visibility (what a rep can see) live as two sub-tabs of one Roles & Access tab.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →