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 the work visible in that team	Workspace Owner or Admin; Team Admin for that team’s details

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.

Role	What it grants
Workspace Owner	Workspace ownership and sensitive workspace-wide controls; can administer every team
Workspace Admin	Workspace settings, members, invitations, and every team
Workspace Editor	Day-to-day product work; can change an accessible initiative’s assignments for teams where they also have Team Admin or Team Editor access
Workspace Viewer	Read-only participation; no workspace administration
Team Admin	Manage that team’s name and description and edit its work; does not grant workspace administration or access to workspace members
Team Editor	Create and update work in that team
Team Viewer	View work in that team without changing it

A Team Admin can have a lower workspace role. Team Admin does not make the person a Workspace Admin and does not expose the Members tab, integrations, API keys, billing, or other workspace-wide settings.

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.

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.
• 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.
• 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 and appear only in that team’s Huddle space.
• Start the Huddle from the team that owns the meeting and its review queue.

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 that read or change initiatives and Studies use the signed-in person’s team memberships. A tool can optionally target one accessible team; otherwise it uses the teams available to that person. It cannot use a team identifier to bypass membership.

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. 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.