Members & Roles

Invite teammates to your workspace and assign a role. Roles exist at workspace, project, and team level, but the current permission model is intentionally coarse: it is not a feature-by-feature or read-only permission system.

Inviting members

Invite people by email from workspace settings. An invite is redeemed by the recipient after they sign in, and it can be resent or removed while it is still pending. Invite someone as a regular member or as a guest, then add the people who need access to the relevant project.

What the roles currently mean

There are four workspace roles: Owner, Admin, Member, and Guest. Project and team memberships use Admin, Member, and Guest. Workspace administration routes require an Owner or Admin. At project and team level, admin-only routes require an Admin, member routes allow Admins and Members, and guest routes allow all three roles.

In practice, many everyday workspace routes currently admit every workspace role, including Guest, and a number of project actions use the guest-level guard. That means Guest should not be described as view-only, and a role alone does not tell the whole story of a person’s access. Project membership and the specific action still matter.

If you need a hard boundary, use a separate workspace or a private project and review its membership. Treat the current roles as broad collaboration roles, not as an exhaustive security policy.

Guests

Guests are useful for external collaborators and people who should not be workspace administrators. They can be invited to a workspace or join a joinable project, which creates a guest membership. Because guests can be allowed through several normal project and workspace actions, give them access only where that level of collaboration is appropriate.

For people who do not need an account or to participate, use a shared page instead.