Skip to main content
A team is a named collection of users you can grant access to as a single subject. Instead of adding ten people to an entity one by one, you add the team once, and everyone in it gets that access. Add or remove a member and their access updates everywhere the team is used.

​
What a team is

A team has a name, an optional icon, and a set of member users. A user can belong to any number of teams, and teams can nest up to three levels deep (Sales › SDR pod). A member of a sub-team inherits whatever its parent was granted. Manage them from Settings → Teams. Teams are typically named by role or department:

​
Creating a team and adding members

1

Create the team

Go to Settings → Teams and click Create Team. Give it a name (and optional icon).
2

Add members

Open the team to manage its membership, then add the users who should belong to it.
3

Save

Members are added immediately. No other setup is required to start using the team in permissions.

​
Granting a team access

Teams earn their keep on permissions. Anywhere Custral asks you to pick a subject (the access editor on any entity, or the Workspace panel in Settings → Permissions) you can pick a team instead of an individual. Every member then inherits that access level.
1

Open the access editor

Open the entity you want to share (an object, page, record, or the Workspace panel) and open its access editor.
2

Add the team as a subject

In the subject picker, choose the team from the Teams list rather than an individual user.
3

Choose a level and save

Pick an access level: Read, Edit, Admin, and so on. Save.
Example: grant the Sales team team Edit access to the Deals object, and every member can edit all deals. Add a new rep to the team later and they gain the same access immediately, no per-entity setup.

​
How overlapping access resolves

A user often has access from more than one source. A direct grant plus one or more team grants. When they overlap, Custral applies the highest level. Granting a team a lower level never reduces access a member already has from elsewhere; to restrict access, remove the broader grant or turn off inheritance on the specific entity.

​
Teams and inheritance

A team grant behaves like any other grant on the permission hierarchy: place it on a parent (an object, a section, or the Workspace) and it flows down to child entities that inherit, unless a narrower grant overrides it. This is what makes teams scale: set access once at a high level, and it cascades to everything beneath.

​
Best practices

1. Prefer teams over individual grants Assign access to a team whenever more than one person needs it. It keeps each entity’s access list short and easy to audit. 2. Name teams clearly Use descriptive, role-based names like All admins, Sales team, or Customer success so it’s obvious who a grant reaches. 3. Review membership regularly Check team membership periodically (especially when people change roles or leave), so access stays current.