Config tables only an owner can change

Settings that define how the whole account behaves — pricing, stage taxonomy, lead routing, notification routing — can only be written by an admin, enforced at the data layer.

What it is

The data proxy holds explicit sets: tables only admins may read, tables the field 'worker' role may not read, tables nobody may write through the proxy at all, tables only admins may write, and a small named list where delete follows the write roles rather than the admin-only default. Each entry carries the reasoning inline.

Also called: admin only settings · who can change settings · stop reps editing config

See it
Config tables only an owner can change
Day rate
$600
Days figured
5
Crew size
3
Fuel & equipment
$300
Finished 2 days early — $1,800 back to the crew
A permissions table rendered from the allowlists: table name, who can read, who can write, who can delete. Source: the constant sets at the top of src/app/api/db/route.ts. Sample data — no customer information appears here.
How it works
  1. 1Reads: admin-only tables include the audit log, invitations, join requests, lead visibility policy, lead routing configuration and notification routing.
  2. 2Worker-excluded reads cover service pricing, labour time entries and expenses, and stage assignments — a worker's own hours come from a dedicated, server-derived endpoint instead.
  3. 3Write-forbidden tables must go through their dedicated endpoints, so invitations, join requests and notifications can't be forged through the generic proxy.
  4. 4Admin-only writes cover pricing, permission presets, stage automation rules, identity mappings, lead routing and the account's project-stage taxonomy.
  5. 5A short exception list lets non-admin write roles delete the things they were allowed to create — pipeline card links, suppressed leads, saved snippets, saved designs.
Why we built it

Each gate documents the specific hole it closes. On the stage taxonomy: it 'sat outside this list while its sibling stage_automation_rules was inside, so any sales rep, PM or crew lead could replace the entire taxonomy with one /api/db upsert.' On notifications: rows are written only server-side and read through user-scoped routes, because otherwise 'a member could select or forge other users' notifications.' On labour data: gating here 'stops a worker from enumerating coworkers' submitted time/expenses org-wide via a crafted select.' And the delete exceptions exist because a one-way permission is a bug in practice — a rep who can link a card must be able to unlink it 'or the card flickers back on the next poll.'

The problem
  • Account-wide configuration was writable by any role that could write anything.
  • A worker could enumerate colleagues' submitted time and expenses through a generic query.
  • Notification rows could be read or forged for other users.
Sound familiar?
What you get
Pricing, routing and stage definitions are owner-controlled.
Field staff see their own work, not the company's payroll data.
Users can undo what they were allowed to do, without gaining admin rights.

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 →