Permissions & Access
Permissions in Business Dash are individual grants — contacts.read,
invoices.manage, and so on — but nobody thinks about a new hire in slugs.
You think "she's running the front office." The permissions screen is built
around that.
Everything here lives at Settings → Permissions and requires an org admin. Org admins themselves implicitly hold every non-platform permission — the toggles below govern everyone else.
Feature groups — click a feature, not a slug
Each member's editor shows the platform as feature cards — Website, CRM,
Invoices, Hiring, POS, and the rest. Every card has a toggle-all: one
click grants the whole feature, another removes it. Expand the card to
subtract (or add) the individual permissions inside — grant the whole Store
group, then remove store.manage for the seasonal hire who should look but
not touch.
One click applies the whole change as a single batch, with one confirmation.
Permission packs — a whole role in one click
Above the feature grid sit packs: role archetypes that grant a coherent job across many features at once.
Built-in packs ship with the platform — Office manager, Field technician, Canvassing rep, Bookkeeper, Marketing manager, Store manager, Front desk / cashier, People ops / HR. Each chip shows live coverage (6/9) so a partially-applied pack is visible at a glance:
- clicking a pack grants its missing permissions;
- clicking a fully-applied pack removes exactly the pack's permissions — anything the member holds beyond the pack is untouched.
Your own packs
Set one member up exactly right, type a name into Save selection as pack…, and the org now has its own pack — appearing beside the built-ins for every member, deletable with the ×. Deleting a pack never changes anyone's permissions; it only removes the shortcut.
Some surfaces can never ride in a pack — platform-staff access, the org admin role, payroll setup (bank/KYB), AR gate override, compliance chat reads, and schema editing are always individual decisions, whether the pack is built-in or org-authored. The platform enforces this on save.
The post-hire checklist
When a hire completes, org admins get a bell notification — "Review permissions — <name>" — linking straight to this screen with the new member's editor open. Job postings apply their default permissions mechanically at hire; the human review of that access is the step the notification exists to protect.
Grant by pack for speed, adjust by feature group for precision, touch individual permissions only for the exceptions. That order keeps an org's access legible six months later.