Skip to main content
Live. This area is documented as current, user-reliable behavior.

Goal

Describe the current collaboration model without overstating it into a full enterprise access-control system.

Prerequisites

  • An understanding of the team area

Workflow

1
Use team pages to view members and pending invitations.
2
Use owner-managed actions for invitations, member removal, and role changes.
3
Treat the collaboration model as real and implemented, while avoiding assumptions about deeper enterprise-style RBAC that the product does not surface.

The three roles

  • Owner: full control of the team, including deleting it and managing every member and invitation.
  • Admin: manages members and invitations and day-to-day team collaboration.
  • Member: participates in the team and its shared resources without member-management powers.

What owners can actively manage

  • Inviting new members
  • Changing a member between admin and member roles
  • Removing members from the team

Sharing resources with a team

Collaboration happens by sharing resources with a team: a project can be assigned to a team so its members can work on it, and removed again later. That is the practical purpose of teams — shared access to resources, scoped by role.

Expected result

Team docs reflect the live collaboration model without pretending it is a different class of access system.

Teams overview

The teams area lets you create teams, view team membership, and manage team-level collaboration flows.

Invitations

Accepting and managing invitations is a user-visible part of the collaboration model.