Skip to content
Fredrin
Documentation

Teams & security

Workspaces, members and roles

A workspace is where billing and people live. Access, though, is granted per project, which is the detail worth understanding before you invite anyone.

Workspace and project

A workspace is the billing and home container: members, plan, teams.

A project is one repository and its board.

Access is gated on the project. Being in a workspace does not, by itself, let you see a project inside it. That is deliberate: it means inviting a contractor to one repository does not hand them every repository you own.

Two ways to get access

  1. Project membership. You were invited to that specific project. You see that project and nothing else.
  2. Organization access. You accepted a workspace-level invitation, or you own the workspace. You see every project in it.

The distinction is the whole model. A workspace-level invite makes an organization member; a project-scoped invite makes a single-project collaborator who happens to also hold a workspace row.

If you are inviting someone to help with one repository, invite them to the project.

Roles

Owner manages billing, members and workspace settings.

Member does the work: create and run tickets, review and merge, within the projects they can reach.

An API key inherits the role of whoever created it, so a key can never do more than its owner.

Teams

A team is a named group of workspace members. They do three jobs:

  • Ticket assignment. A ticket can be assigned to any number of teams, independently of who its individual assignee is.
  • Board filtering. Filter to work assigned to a team.
  • Project access. Grant a whole team access to a project at once.

Teams are the answer to "who owns this area" without making it one person's queue.

Plans

Entitlements that differ by plan include the number of projects, private repository support, and team collaboration.

See pricing for the current tiers.

Next steps