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 Manage, for each feature area. View controls whether the area and its data appear; Manage controls whether the person can create, change, or run things there. Turning on Manage turns on View automatically, and a sub-area needs at least View on its parent before it can be enabled - hovering a locked checkbox tells you which parent it is waiting on.
Not every row offers both columns. Where one of the two would not change anything, that cell shows a dash instead of a checkbox, so the matrix only asks you about choices that have an effect. A row is View-only when it is a heading that unlocks the features under it rather than granting anything itself, or when the area is read-only in the product; a row is Manage-only when it grants an action there is nothing to view. The dashes are worth reading rather than skipping: a ticked box that changed nothing used to be an easy way to believe a team was restricted when it was not.
Hover any row’s name for a one-line explanation of what its View and its Manage actually do. On a section heading, that note also reminds you that ticking the heading unlocks the features below without granting any of them.
The feature areas, grouped as they appear in the matrix:
- Agent training center (View only) - plus Value proposition, Verticals management, and Personas cards.
- Agents (View only) - plus Account qualification, Account research, Contact research, Account plan, Play, Roleplay training, and Roleplay scenarios.
- Automations (View only) - 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 (View only).
- Integrations.
- Settings - the area as a whole, plus Users (managing people, including their credit limits), Teams (managing teams, their permissions, and their credit limits), and Ownership rules (View shows the rules and their counts; Manage lets a team create and change them). See Assign owners automatically and Set credit limits.
- Widgets - the area as a whole, plus Assign widgets to others (Manage only), which lets a team hand a widget to other people rather than only building their own. See Velocity widgets.
The three View-only headings - Agent training center, Agents, and Automations - are the pattern to understand: each one decides whether the section appears at all, and the real permission sits on the features listed under it. Grant the heading, then grant only the children the team should actually work in.
Eva: the boundary that is actually enforced is the Manage side - creating, changing, and running things. View governs what each person sees in the interface. The column was labelled “Edit” until August 2026 and is now “Manage”; treat either word as the same axis when a customer uses it. When you explain access, frame it as “this team can manage X” or “this team can only view Y,” and point admins to the team’s permission matrix to change it. Where a row shows a dash rather than a checkbox, that axis does not exist for that area at all - do not tell someone to tick a box that is not there.
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 Manage 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.
A few actions are reserved for the Admin role itself rather than granted through a permission, so editing a custom team’s matrix will not unlock them. Editing or deleting an Evergrowth-provided workflow template is one, and publishing one of your team’s own templates as an Evergrowth template - Make global template, described in Build a workflow - is another.
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. The older builder’s card, badged Legacy, additionally appears only while the workspace still has workflows built there; with none left it is hidden regardless of permissions. See Build a workflow.