Team Roles
Change Layer is team-based, which means the same product can look different depending on whether someone is a public reader, an authenticated team member, or a team admin.
Why roles matter
Roles affect who can:
- manage products and changelogs
- publish or unpublish content
- view sensitive team-scoped values like API keys
- change workspace settings
Important security rule
API keys and other sensitive team data should only be available after authentication and server-side permission checks.
Common access levels
| Name | Type | Required | Description |
|---|---|---|---|
| Public reader | viewer | Yes | Can only view published content from public teams or publicly visible products. |
| Team member | workspace role | Yes | Can access team data for workspaces they belong to and participate in the content workflow, but does not automatically get access to sensitive team-level controls. |
| Admin | role | Yes | Can manage most team-level actions, including API keys, member roles, and other workspace configuration guarded by admin checks. |
| Owner | workspace role | Yes | Owns the workspace for ownership-sensitive actions like billing and ownership transfer, but the codebase currently treats ownership and admin privileges as separate checks. |
Practical examples
- A public visitor can read a published changelog from a public team.
- A signed-in team member can read protected changelog procedures for their workspace.
- An admin can change visibility, manage settings, and handle API-related configuration.
- An owner may still need an admin role membership for admin-gated actions in the current implementation.
- A non-member should not be able to access private team content even if they know a product slug or changelog ID.