User guide › Permissions & access
The two systems
| System | Answers | Where |
|---|---|---|
| Entity permissions | Which records can this person see and change? | Members & Permissions → Access |
| Module access | Which apps can this person open, and what may they do in them? | Module Access |
They don't substitute for one another. Giving someone access to the POS app doesn't give them permission to read Customers, and vice versa. Most access problems come down to having set one and not the other.
An admin has full access to everything and won't appear in these matrices — you'll see a note saying as much. If someone can see more than you expect, check whether they're an admin before hunting through grants.
Roles
A role is a named group of people — "Sales Head", "Support", "Warehouse". Roles carry no permissions in themselves; they're a label you then grant access to, so you can set up "what Support can do" once rather than per person.
Grant to roles rather than individuals wherever you can. When someone joins, changes job or leaves, you move them between roles instead of auditing every entity.
Record permissions
The Access tab is a matrix: pick an entity on the left, then set each role and person's level.
| Level | Means |
|---|---|
| View own | See only records they own. The usual starting point for a personal pipeline. |
| View all | See every record in the entity. |
| Create | Add new records. |
| Edit | Change existing records. |
| Delete | Remove records. Deliberately separate from Edit. |
| Admin | Full control of that entity, including its structure. |
The levels combine, so "View own + Create + Edit" is a common shape: someone who manages their own work but can't see anyone else's. A grant can also be scoped to a particular view rather than the whole entity — useful for exposing one filtered slice without opening up everything.
Ownership
"View own" needs the system to know who owns a record. That's an owner field on the entity, filled with whoever created the record.
Because a blank owner field is filled with the record's creator, don't use an owner field on an entity that's a register of other people — a staff directory, say. An admin adding an employee row would silently become that row's owner.
Field-level access
Sometimes the record is fine but one field isn't — salary on an employee record, cost price on a product. Any field can carry its own rules:
- View — only the listed roles, users or teams can see it. For everyone else it's removed from the response entirely, not just hidden in the interface.
- Edit — only the listed subjects can change it; others see it read-only.
Both can carry a condition, so a restriction applies only in certain states — locking an amount once a deal is marked Won, for instance. An empty allow-list means admins only.
Module access
Settings → Module Access controls apps rather than records. Pick a role, person or team, then go app by app.
Each app is either Restricted — only people you've granted can open it — or Open to all. Expanding an app reveals the specific actions it supports, so you can allow someone to use the till without allowing them to void a sale, or to view stock without receiving it.
Actions that spend money or move stock start out admin-only until granted. Read-only actions such as running a report don't, so a team member can use the app's reporting without needing elevated rights.
Teams
Teams group people for ownership and routing — which branch, which department, which shift. They can be used as the subject of a grant, so access follows team membership. See Members, teams & seats.
A workable setup
- Start closedNew members should see very little. It's much easier to add access on request than to discover months later that everyone could read payroll.
- Create roles that match real jobsNot org-chart titles — the actual jobs people do in the system.
- Grant to roles, not peopleReserve per-person grants for genuine exceptions.
- Set both systemsRecord permissions and module access for each role.
- Check it as they'd see itThe fastest sanity check is asking someone in that role what they can see.
When someone can't see something
Work down this list — it's almost always one of these:
- Do they have any grant on that entity? No grant means no access, not read-only access.
- Do they have View all, or only View own — and does the record have an owner?
- Is the app itself Restricted with no grant for them?
- Is a specific field restricted rather than the whole record?
- Is the grant scoped to one view that they aren't looking at?