Tune a role for how you actually run

Override what a built-in role can do for your company, or define named presets of your own, without changing anyone else's account.

What it is

A per-account table of permission presets in two flavours: a built-in override that replaces one of the five standard roles for this account only, and a named custom preset anchored to a base role. The standard matrix remains the fallback for any role without an override.

Also called: custom permissions · edit role permissions · permission preset · our own roles

See it
Tune a role for how you actually run
Area
Platform & Admin
Group
Roles & permissions
System
Multi-Tenancy & Identity
Solves
3 named problems
01Presets are stored per account and read through the account-scoped data proxy.
02A built-in override is flagged as such and names which standard role it replaces.
03resolveBuiltinPermissions() is the single read path for 'what does role X look like for this tenant'.
The preset editor with a built-in role selected and individual capability toggles flipped, plus a 'custom preset' list. src/components/settings/PermissionPresetsTab.tsx. Sample data — no customer information appears here.
How it works
  1. 1Presets are stored per account and read through the account-scoped data proxy.
  2. 2A built-in override is flagged as such and names which standard role it replaces.
  3. 3resolveBuiltinPermissions() is the single read path for 'what does role X look like for this tenant'.
  4. 4Writes to the presets table are admin-only, enforced server-side as well as in the settings UI.
  5. 5Any role without an override falls back to the canonical matrix.
Why we built it

Post-frame builders don't run identically — one owner wants crew leaders approving time, another wants that with the office only. The module documents the two flavours precisely so the override case can never be confused with a new role: a built-in override is 'a tenant-specific replacement for one of the five hardcoded role presets', identified by its flag and the role it replaces. Making resolveBuiltinPermissions() the single read path is what stops a screen rendering the canonical matrix while the server enforces the tenant's override.

The problem
  • Fixed roles never match every company's division of labour.
  • Per-person checkboxes make 'who can see billing' a query rather than a glance.
  • Two code paths reading permissions differently causes UI and server to disagree.
Sound familiar?
What you get
You adapt roles to your company without waiting on the vendor.
Overrides are scoped to your account only.
One resolver means the screen and the server always agree about what a role can do.

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 →