Team roles and work access

Think of the two levels this way:

Level	Controls	Typical administrator
Workspace	Members, workspace roles, settings, integrations, API keys, billing, and workspace identity	Workspace Owner or Admin
Team	Operational membership, team roles, and who can open the team’s work	Workspace Owner or Admin; Team Admin for that team’s details and people

A person first belongs to the workspace and then to one or more teams. Every workspace member must belong to at least one team. This prevents a valid workspace account from landing in an empty, unusable state.

Team membership does not replace workspace membership. Removing someone from one team leaves their workspace access and other team memberships unchanged. To remove workspace access entirely, use the Members tab.

The default team is created with the workspace and initially uses the workspace name. It owns:

• existing initiatives and team-owned records when teams are first enabled
• new work created without an explicit team
• work created while the default team is selected

The default team is a real team, not an “all workspace” view. New teams do not automatically share their initiatives with it.

For example:

• Creating an initiative while Team A is selected assigns only Team A.
• Adding Team B later assigns Team A and Team B.
• The initiative does not also belong to the default team unless someone explicitly adds it.

New workspace members join the default team unless they are invited directly into a specific team. A member can be removed from the default team after they belong to another team. The default team itself cannot be deleted.

Workspace roles and team roles answer different questions, and are set separately.

Your workspace role decides what you may change about the workspace itself.

Role	What it grants
Owner	Workspace ownership and sensitive workspace-wide controls; can administer every team
Admin	Workspace settings, members, invitations, and every team
Editor	Day-to-day product work, in the teams you belong to
Viewer	Read-only by default; no workspace administration

A workspace Owner or Admin can enable Manage studies and panels in Settings → Members → a person’s details. This lets the person create, edit and launch all studies, manage panels and audiences, and read results and participant identities, including future studies. It does not change their workspace role, add team seats, or open private initiatives. Choose this when someone runs research across teams.

Your role in a team decides what you may change about that team’s work.

Role	What it grants
Admin	Manage that team’s name, description and people, and edit its work
Editor	Create and update work in that team
Viewer	View work in that team without changing it

The two are independent: a Team Admin can hold any workspace role, and Team Admin never opens the Members tab, integrations, API keys, or billing.

Workspace Owners and Admins can always open Settings → People → Teams and administer team membership, even when they are not operational members of a team. This administrative ability does not add the team to their selector or automatically place that team’s work in their normal initiative view.

A Team Admin adds people to their team, changes their team role and removes them. They can’t change anyone’s workspace access, so a workspace Viewer joins as a Viewer. Inviting new people, service members and the team seats of workspace Owners and Admins stay with workspace admins.

You can open a team’s work, meaning its initiatives, the Studies linked to them, its Huddle and its cycles, when any of these is true:

• you’re in the team, in any role
• the team is open to Everyone in the workspace
• a workspace admin gave you Reads every team’s work in Settings → People. No role includes it: Owners and Admins give it to themselves like anyone else, and every change is in the access history

Reading a team you’re not in is read-only. It adds nothing to your own team menu, Home or Huddle. For a team open to everyone, Add to my teams gives you a Viewer seat so it appears in your own views. A read grant for a private team does not let you join it; ask a team or workspace admin to add you. For workspace Owners and Admins any seat also lets them change the team’s work, and the button says so before they choose it.

Who can open this team’s work sits beside the team’s name in Settings → People → Teams. Every team starts as Only people in this team. Workspace Owners and Admins can open a team to everyone in the workspace, and its Team Admins can close it again. The default team has no setting, because everyone is in it.

When you can’t open something, Zentrik names the team and who can add you, never the record: “Only people in Growth Pod can open this. Ask Dana Ruiz (Growth Pod admin) to add you.” Workspace Owners and Admins can add themselves instead, with Add to my teams. Discovery, previews, product context and coding-agent briefs leave out initiatives you can’t open.

Access history. Each team records who added or removed whom, role changes, people adding themselves, grants to read every team and changes to the setting, with who made each change and when. Workspace admins and the team’s admins read it from Team actions → Access history and can download it as CSV. Zentrik doesn’t record who read a team’s work yet.

Team scope follows the work, not only the navigation.

Initiatives

• Every initiative belongs to at least one team.
• Creation uses the selected team. Older clients or flows that omit a team use the default team.
• Changing an initiative takes a workspace role other than Viewer and Team Admin or Team Editor access in one of its teams. For Workspace Owners and Admins, any role in one of its teams is enough.
• Workspace Owners and Admins can change the assigned teams from the initiative properties.
• Workspace Editors can add or remove a team when they can edit the initiative through an assigned team and have Team Admin or Team Editor access in every team whose assignment changes. Teams where they have Viewer access remain visible but read-only.
• An initiative can belong to multiple teams when the work is shared across teams.

Studies

• A Study linked directly or through an accepted link to an initiative follows that initiative’s team access. Manage studies and panels adds Study access across the workspace without granting access to the private initiative itself.
• Studies without an initiative relationship remain workspace discovery records.
• The selected team filters initiative-linked Studies to the work available in that team.

Huddles

• Huddles belong to one team. Anyone who can open the team’s work can read its Huddle, and a look from outside the team never counts as the team opening it.
• Start the Huddle from the team that owns the meeting and its review queue.
• Changing a Huddle, including assigning or resolving its blockers and decisions, takes Team Admin or Team Editor access in that team. For Workspace Owners and Admins, any role in that team is enough, as for its initiatives.

Cycles and tasks

• Cycles belong to one team.
• Standalone tasks must have a team.
• Initiative tasks follow access to their initiative and its assigned teams.

If shared work is moved from one team to another, update the owning team before removing old membership. This avoids making the record disappear from the people who still need it.

See Documents and delivery for the reviewed path from an owned initiative to artifacts, stories, tasks, and external delivery systems.

MCP tools see the initiatives and Studies the signed-in person can open in Zentrik, and change only what that person can change. A tool can target one team; it cannot use a team identifier to reach work the person can’t open.

Agents can use teams.list to resolve the teams you can access without reading team membership. When creating shared work, initiatives.create accepts one or more team IDs. Workspace Owners and Admins can use initiatives.set_teams to replace an existing Initiative’s complete team set after review. Older MCP grants may require reconnecting before these tools appear.

Workspace API keys remain workspace-scoped and read every team’s work, whatever a team’s setting. The team selected in the Zentrik navigation does not narrow an API key. Treat API-key holders and automations as workspace-wide integration principals, grant only the scopes they need, and rotate or revoke keys when responsibility changes.

See MCP setup and the REST API reference for authentication and scope details.