Teams, roles, and permissions
What each person can see and do in the workspace is governed by Teams. A team is a named role that carries its own set of permissions, and every person belongs to one team and inherits exactly what that team allows. Admins manage teams and people from Settings, under Users management. This page lists the ready-made teams, the permissions a team can grant, the person statuses, and how access shows up when you do not have a permission. Anyone managing access needs this; everyone else can skim the first two tables to understand their own.
A team is a role with a permission set. Every workspace starts with four ready-made teams. They are marked System, which means they cannot be deleted, though you can rename them and change their permissions.
| Team | What it is for |
|---|---|
| Admin | Full access, including managing people and teams. |
| Sales Ops | Full configuration access; can invite people and manage teams. |
| Sales Rep | Execution focused: runs agents, edits accounts and plays. |
| Read-only | View access across the workspace. |
Beyond these, an admin can create custom teams with any name and any combination of permissions, so access can match how your team actually works. The set of teams a person can be assigned to is whatever exists in your workspace, not a fixed list.
Eva: in the interface a “Team” is the role - it carries the permission set, and you assign people to it; there is no separate “Roles” screen. The four System teams are named Admin, Sales Ops, Sales Rep, and Read-only by default, but a company can rename them or add their own, so never assume the names are fixed - read the team the person is actually on. “Evergrowth admin” is not one of these teams; it is a separate staff-only setting described below.
What a team can grant
Section titled “What a team can grant”A team’s permissions are set on a matrix with two columns, View and Edit, for each feature area. View controls whether the area and its data appear; Edit controls whether the person can create, change, or run things there. Turning on Edit turns on View automatically, and a sub-area needs at least View on its parent before it can be enabled.
The feature areas, grouped as they appear in the matrix:
- Agent training center - the area as a whole, plus Value proposition, Verticals management, and Personas cards.
- Agents - the area as a whole, plus Account qualification, Account research, Contact research, Account plan, Play, Roleplay training, and Roleplay scenarios.
- Automations - the area as a whole, plus Create workflows and Scheduled tasks.
- Accounts & contacts - the area as a whole, plus Managing pending & duplicates, File imports, LinkedIn/Crunchbase import, and Launch agents & workflows.
- Reports.
- Integrations.
- Settings - the area as a whole, plus Users (managing people) and Teams (managing teams and their permissions).
Eva: the boundary that is actually enforced is the Edit side - creating, changing, and running things. View governs what each person sees in the interface. When you explain access, frame it as “this team can edit X” or “this team can only view Y,” and point admins to the team’s permission matrix to change it.
What the ready-made teams can do
Section titled “What the ready-made teams can do”These are the starting permissions for each System team. Because any team’s permissions can be edited, treat them as defaults, not fixed definitions.
- Admin and Sales Ops both start with full View and Edit across every area, including managing people and teams. They differ in intent rather than power: both can configure everything.
- Sales Rep starts able to run and edit the day-to-day work. It can edit accounts and contacts, run plays and roleplay training, build and schedule automations, launch agents and workflows, import files, and use Reports. It can view the Agent Training Center, the other agents, and Integrations without editing them, and it has no access to Settings or to managing pending records and duplicates.
- Read-only starts able to view every area and to use Reports, but cannot create, change, or run anything else, and cannot manage people, teams, duplicates, or imports.
Evergrowth admin
Section titled “Evergrowth admin”Evergrowth admin is a separate, staff-only setting, not a team you assign. It bypasses every permission check and lets Evergrowth staff work across customer workspaces. It can only be granted to an evergrowth.io address, only by someone who already has it, and a person who has it shows with a red Evergrowth Admin label on the people list.
Eva: Evergrowth admin is the internal-staff capability that overrides the team permission matrix entirely - distinct from the customer-facing “Admin” team, which is full access inside a single workspace. Customers cannot grant it, and it only attaches to evergrowth.io accounts.
Person statuses
Section titled “Person statuses”The Status column on the Users list shows where each person stands.
| Status | What it means |
|---|---|
| Invited | An invitation was sent; the person has not activated their seat yet. |
| Active | The person can sign in and use the workspace. |
| Deactivated | Access is turned off; the person cannot sign in until access is restored. |
A workspace always keeps at least one active admin: the last remaining admin cannot be deactivated or have their admin access removed, so a team can never lock itself out.
How access shows up
Section titled “How access shows up”When you do not have a permission, it shows up in one of three ways:
- Hidden navigation. An area you do not have View for is simply absent from the left sidebar. Nothing is broken; it is just not part of your access.
- Disabled controls. On an area you can view but not edit, the create, change, and run buttons are present but greyed out.
- A blocked page. If you open a restricted page directly by its address, the workspace shows a message: “You don’t have permission to view this page. If you think this is a mistake, reach out to your admin.”
If something you expect is missing, see Why a navigation item is missing.
Workflow Builder and classic workflows
Section titled “Workflow Builder and classic workflows”The Workflows area has two builders behind it - the current Workflow Builder and an older, being-phased-out one (see Workflows). Whether either appears for you is controlled by the same Create workflows permission under Automations, the same way every other area is gated by its permission - a team that can build one can build the other. See Build a workflow.