Members, Teams, and Roles

Who can do what, managed in one place. Every action in the product is permission-checked server-side; roles are how those permissions are granted.

Members

Invite members by email; each holds one role in the organization. The built-in roles cover the common shapes: viewers who read, architects who design and decide, reviewers who judge, and org admins who administer. On the Medium plan and above, custom roles let you compose permissions to match your own titles.

Teams

Group members into teams for assignment and filtering. Team structure is organizational convenience; permissions always come from roles.

Separation of Duties

Governance actions enforce separation server-side: reviewers judge work they did not author, and risk sign-off comes from someone other than the person whose work created the risk. These are rules the platform enforces, not conventions it hopes for.

Automated Provisioning

On the Large plan and above, connect your identity provider for single sign-on, and provision membership automatically from your directory: joiners get access, movers change roles, and leavers lose access when your IdP says so, without anyone remembering to click.

Least Privilege Is Free Here

Viewers see everything they need to follow a package's story: the design, assurance results, readiness, and diagrams. Grant write-capable roles only where someone actually decides.