Organize work with teams

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 Settings → Workspace access.

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; no workspace administration
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 Workspace access, integrations, API keys, billing, or other workspace-wide settings.

Workspace Owners and Admins can always open Settings → 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.

Open Settings → Teams.

To create and configure a team:

1. Choose Create team and enter a recognizable name and purpose.
2. Select the team in the left rail.
3. Click the name or description to edit it in place.
4. Choose Add member to search existing workspace members or invite a new person.
5. Assign Admin, Editor, or Viewer for that team.

The members table can be searched and filtered by team role. Workspace Owners and Admins can change roles or remove members. A Team Admin can edit that team’s name and description, but cannot browse workspace users or change team membership unless their workspace role also permits it.

When an invited person does not yet have a Zentrik account, the invitation creates their workspace membership after acceptance. A writable team role receives Workspace Editor access; a Team Viewer receives Workspace Viewer access. Team Admin never elevates the workspace role to Workspace Admin.

Use Settings → Workspace access or Settings → Workspaces to review every workspace member, their workspace role, and all team assignments. Change the workspace role there rather than through the team role selector.

The selector at the top of the main navigation lists the teams you belong to. Choose a team to make it the active operating scope.

The active team determines where new team-owned work is created and which team’s work is shown in team-aware views. Changing teams does not change work ownership; it changes the scope you are viewing and creating in.

The selector also provides shortcuts to team settings and, for Workspace Owners and Admins, workspace user management. If you belong to more than one workspace, switch workspaces from the user menu. The team selector never changes the workspace itself.

Workspace Owners and Admins can choose All workspace initiatives where that view is offered. It is a privileged view, not a team and not an assignment that makes initiatives visible to other members.

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.
• An initiative can belong to multiple teams when the work is genuinely shared.

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.

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.

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.

Use a staged rollout:

1. Release the default team first. Existing workspace members and legacy team-owned work remain together in the default team.
2. Keep normal work unchanged. While everyone uses only the default team, new initiatives, Huddles, cycles, and standalone tasks continue in the shared scope.
3. Create the operating teams. A Workspace Owner or Admin creates the pods, product groups, or delivery teams.
4. Assign people before work. Add each person to the teams they need with the least team role that supports their job.
5. Move initiatives deliberately. Reassign initiatives to the right team or teams. Check linked Studies, Huddles, cycles, and standalone tasks as part of the move.
6. Remove broad default-team membership last. Once a person has another team and their work has been reassigned, remove them from the default team if the shared scope is no longer appropriate.

Until steps 3–6 begin, members should experience the same shared workspace behavior they had before teams. The compatibility promise depends on keeping everyone and existing work in the default team during the first stage.