--- title: "Team roles and work access" canonical_url: https://zentrik.ai/docs/product/team-access-reference markdown_url: https://zentrik.ai/docs/product/team-access-reference.md category: "Product guides" learning_track: "administration" last_reviewed: 2026-09-21 --- # Team roles and work access Check what workspace and team roles permit, which work a team can access, and how API access differs. ## 2. Understand the workspace and team model 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. ## 3. Use the default team as the compatibility layer 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. ## 4. Separate workspace roles from team roles 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. ## 7. Know which work belongs to a team 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](https://zentrik.ai/docs/product/documents-and-delivery) for the reviewed path from an owned initiative to artifacts, stories, tasks, and external delivery systems. ## 8. Understand MCP and API boundaries 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](https://zentrik.ai/docs/integrations/mcp) and the [REST API reference](https://zentrik.ai/docs/api) for authentication and scope details. ## Related guides - [Administer a Zentrik workspace safely](https://zentrik.ai/docs/product/workspace-administration) - [Set up the Ideas Portal](https://zentrik.ai/docs/product/ideas-portal) - [Invite people and manage access](https://zentrik.ai/docs/product/workspace-access)