Organize work with teams

Open Settings → People, then choose Teams.

1. Choose Add team at the end of the team rail.
2. Give the team a recognizable name and a short purpose.
3. Select the team, then choose Add members.
4. Choose existing workspace members or Invite new people. If everyone is already on the team, the invitation form opens directly.
5. Assign Admin, Editor, or Viewer for this team.

You can invite several new people together when they need the same access. The invitation summary shows the workspace and team roles before anything is sent. For the complete first-batch invitation flow and pending states, see Invite people and manage access.

A service member represents a person or bot that needs to own work without signing in. In Teams, workspace Owners and Admins can open the arrow beside Add members and choose Create service member. The main Add members button opens the usual member and invitation flow.

Enter a name and optionally set delivery roles, abilities, and average cycle velocity in story points. The member appears in the team roster and task owner selectors immediately. The roster lists named users first by default, followed by accounts labeled Service member, with names alphabetical within each group. You can edit its teams, team roles, and delivery profile like any other member.

To give the member sign-in access, open its row actions and choose Invite to sign in. Enter an email address that does not already belong to a Zentrik account. The recipient follows the usual invitation and registration flow. Their assignments, delivery profile, team memberships, and history remain attached to the same member.

Until acceptance, the roster still identifies the account as a Service member. Use its row actions to resend, copy the invitation link, or revoke the invitation. Revoking or letting an invitation expire leaves the member and its work intact. Revoke an existing invitation before choosing a different email address.

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.

Open Settings → People, then choose Teams.

Select the team in the left rail. Open Team actions to edit the team's name and purpose, switch your product context to it, or delete it. Choose Add members to bring workspace members into the selected team, and into any other teams they should join at the same time.

Search the team rail when the workspace has several teams. Teams whose names share a prefix, such as Roadmap - Payments and Roadmap - Scheduler, are grouped under that prefix so the part that tells them apart stays readable.

The member table answers access questions: who belongs to the team, the role they hold, how many other teams they are in, and when they joined. Choose the Also in count to see those teams and their roles. Member search matches the person, email, role, and other team memberships, so an administrator can check the wider access context before making a change; pending rows show when the invitation was sent. Delivery roles and cycle velocity appear once someone on the team has a delivery profile that carries real values.

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

The invitation dialog states the workspace access that the team role will give a new person. Enter several email addresses when the first group needs the same access. The default summary stays visible; choose Change only when a different workspace or team role is required. 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.

Change several memberships at once when a team reorganizes. Select rows in the member table to set the same team role for everyone selected, add them all to further teams, or remove them from this team. Anyone whose only team is this one is named and kept, because every workspace member must belong to at least one team.

To move one person instead, choose Edit teams from their row. That lists every team with the role they hold in each, and saves the whole change together, which is the quickest way to place a new joiner across the teams they will work in.

Use Members to review every workspace member, their workspace role, and all team assignments. Change the workspace role there rather than through the team role selector. Use Switch workspace in the top-left team menu before administering another workspace. Use Workspaces to create, name, and set workspace defaults.

The team menu at the top of the main navigation lists the teams you belong to. Choose a team to decide which team’s work you are viewing and where new team-owned work is created.

Changing teams does not change existing work ownership.

The menu also provides shortcuts to team settings and, for Workspace Owners and Admins, Invite people. If you belong to more than one workspace, open Switch workspace in the same menu. Workspace choices are alphabetical, searchable for larger lists, and contained in a scrollable panel.

Settings keeps the same current-team menu as the rest of Zentrik. Choosing a team there changes product context. Choosing a team in the Settings rail only selects it for administration. Use Switch workspace in the current-team menu before administering another workspace.

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

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.

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.