Design a role: what permissions govern
Permissions are grouped by what they govern: the business itself, the structure of your collections, the records inside them, the stages work moves through, and invitations. The most useful line to draw is between changing the structure and working with records — and one permission decides whether a person sees every record or only the ones assigned to them.
Requirements: a role that can manage users and roles.
A role is a bundle of permissions, and building a good one means knowing what the permissions actually govern. They fall into a few areas, and the distinctions between them are what let you give someone exactly the access their job needs.
The areas permissions cover
- The business itself — viewing it, updating its settings, and team-wide display preferences. Deleting a business sits here too, which is not something to hand out casually.
- Structure — viewing and managing collections and their fields, and archiving collections. This is the power to reshape the model.
- Records — creating, updating, and deleting entries, importing them in bulk, and seeing every entry rather than only your own.
- Stages — viewing, creating, updating, and removing the stages entries move through.
- Invitations — viewing, sending, and managing invitations to the business.
The most important line: structure versus records
Notice that changing the structure of a collection and working with the records in it are separate permissions. That separation is the single most useful thing here.
Most people on a team need to create and update records all day, and never need to add a field or archive a collection. Giving them record permissions without structure permissions means they cannot accidentally reshape the model everyone else depends on — while losing nothing they actually need. Reserve structure permissions for the few people who own how the model is built.
Seeing everything, or only your own
One permission deserves particular attention: seeing all entries. In collections that have an assignee field, a person without it sees only the entries assigned to them, plus the ones nobody has taken. With it, they see the whole collection.
This is how you build a sales floor where each rep works their own accounts, or a support queue where agents pick up unassigned items — and it is also why a manager needs this permission to see the team's work rather than just their own. If someone reports that records "disappeared", check this before assuming anything is broken: they are almost certainly assigned to someone else. Administrators have it implicitly.
Importing is its own permission
Bulk import is separate from creating records one at a time, and sensibly so — an import can add or change thousands of records in one action. Grant it to the people who genuinely load data, not to everyone who can create an entry.
Designing a role
Start from the job, not from the list. Write down what the person does all day, translate that into the areas above, and grant nothing else. A support agent might need records (create, update, see all) and stages, and nothing at the structure or business level. An operations lead adds structure. Only an administrator needs everything.
Widening a role later takes seconds; discovering that everyone could archive collections takes longer and costs more.
Notes and limitations
- Structure and records are independent — someone can manage records without being able to alter the model.
- Without "see all entries", a person sees only entries assigned to them or unassigned, in collections that track an assignee.
- Administrators hold everything implicitly, including seeing all records — be deliberate about who is one.
- Bulk import is a separate permission from creating entries.
- Permissions belong to the role, not the person — to change what someone can do, change their role or move them to another.
Related
The model behind users, roles, and permissions is in how access works; adding someone is in invite a user. Roles also bound what an agent can do — see how an agent connects.