Who Can See What
Every button you see, every list you can open, and every action you can take is controlled by permissions. This page explains the model in plain language — what a permission is, how permission groups work, why a space can cap what anyone can do inside it, and how to find out exactly why someone can or cannot do something.
The building blocks
- Permission — one very specific capability, like "read contacts", "delete contacts", or
"export this table". Permissions are deliberately fine-grained so access can be tailored precisely.
- Permission group — a named bundle of permissions, and possibly of other groups. Groups are
the only way permissions are ever granted — never one key at a time to one person. Think of a group as a role: "Sales", "Read-only auditor", "Space admin".
- Space ceiling — each space (your team's workspace) is itself assigned groups, and together
they form the maximum anyone can do in that space. If the ceiling does not include "delete contacts", then nobody in that space can delete contacts — not even a super admin.
which records you see (categories, pipelines); permission groups control which actions you
may take. The two are completely separate systems.
Roles that build on each other
Groups can contain groups, so roles extend naturally: a "Viewer" group might hold all the read permissions; "Editor" contains the Viewer group plus write permissions; "Manager" contains Editor plus approval rights. Grant a person the one role that fits, and it brings everything beneath it. A group can also carry deny entries — "everything in Editor, except deleting" is one small deny group away.
Two special flags exist for administrators: a space admin group automatically accumulates the permissions available in its own space, and a super admin group (held in the root space) reaches across every space. Neither flag bypasses the rules below.
How your effective permissions are calculated
For any user, in any space, the system resolves four sets and combines them — the same way for everyone, with no special cases:
- Your allows — every permission reached through the groups you hold.
- Your denies — every permission any of your groups explicitly denies.
- The space's allows — everything the space's assigned groups permit (the ceiling).
- The space's denies — anything the space explicitly denies, carved out of the ceiling.
The formula, in one line:
effective = (your allows − your denies) ∩ (space allows − space denies)In words: take what your groups grant, remove anything you are denied, then keep only what the space itself allows (minus anything the space denies). You end up with the overlap of the two — what both you and the space agree you may do.
Three rules fall out of this, in strict order:
| Rule | Meaning |
|---|---|
| Deny always wins | If any group you hold — or the space — denies a permission, you do not have it. Nothing overrides a deny, not even super admin. |
| The ceiling binds everyone | If the space's ceiling lacks a permission, no one has it there. A super admin "has everything" only in spaces whose ceiling is everything. |
| Otherwise, allowed is allowed | A permission granted by your groups, not denied anywhere, and inside the ceiling, works. |
Worked example. Dana holds "CRM Editor" (which allows contact delete) plus a "No Purge" group that denies purging. In a space whose ceiling includes delete, Dana can delete contacts but never purge (her deny wins). In a second space whose ceiling has only read and write, Dana can only read and write — her editor grants are clipped by that space's ceiling.
The Permission Tester: find out why
Administrators do not have to reason through this by hand. The Permission Tester takes a user, a space, and (optionally) a specific permission and returns the production verdict with the full explanation:
- Granted — including the exact group chain it flowed through ("via Sales → Editor → contacts.write").
- Denied: explicit deny — some group in the tree denies it, and the tester names the deny path.
- Denied: above the ceiling — the user's groups allow it, but this space's ceiling does not include it.
- Denied: never granted — no group the user holds reaches the permission at all.
its answer is always the real answer — it is a window into the engine, not a simulation.
group tree, or a space ceiling that never included the permission. The tester tells you which in
one click. For how permissions interact with extension fields and record types, see
Roles & Extension Fields.
Where to find it
| Screen | Where it lives | What it is for |
|---|---|---|
Permission groups — /admin/groups | Settings → Workspace & access → Permission groups | compose groups, nest them, grant them |
Permission Tester — /admin/permission-test | Settings → Workspace & access → Permission Tester | the "would this user hold this permission, and why" verdict above |
Elevation Rules — /admin/elevation | Settings → Workspace & access → Elevation Rules | which actions ask for the password again |
Each has its own read permission; saving on each has its own manage permission.
Composing groups
Groups are a global catalogue, and a group is assignable in a space only while that space's ceiling holds it. Inside the ceiling you can compose a group from any permissions it admits, nest groups inside one another, and grant them to your users. The page tells you how many permissions this space's ceiling admits, so you always know what you are composing from.
A group marked available to my sub-spaces shows up in every space below this one — still limited by each of those spaces' own ceilings. A permission declared for a door that has not been built yet is labelled as such rather than quietly offered.
The ceiling itself is set from a space's parent, and never by the space itself — see Users & Spaces.
Elevation rules
Elevation is the second password prompt you meet before a sensitive write. The rules page decides which actions ask for it, and it states the boundary in one line: reads never prompt; only writes can. So no configuration here can turn looking at something into a password prompt — and that is why an elevation prompt always means you were about to change something.