Workspaces & access

The Workspaces and Collaborators primitives define what; this guide explains how to apply them in a real org.

One workspace vs. many

A single-team company uses one workspace. A multi-team company can use one workspace per team or one workspace for the whole company with shared boards. Trade-off: one workspace means simpler billing; many means stronger boundaries.

Member or guest?

The decision isn’t how long someone will be around — it’s whether they’ll touch tracker-linked cards.

Use a member when the person will:

• Create boards
• Edit, import, or export cards that sync to your ADO or Jira tracker
• Manage tracker connections
• Use the API or MCP under their own identity

Use a guest when the person will:

• View boards (read-only)
• Comment, react, mention
• Edit cards that aren’t tracker-linked
• Join workshops or planning without touching the system of record

Every tracker write is recorded with the member who made it. That’s why a write-capable person needs a paid seat and a guest doesn’t.

Picking collaboration roles

Manager for board owners; Editor for working collaborators; Viewer for stakeholders who shouldn’t accidentally edit. Workspace admins always override (an admin is always a manager).

Sensitive boards

For confidential content (compensation, M&A, legal), use a separate workspace, not collaboration-role gating. Workspace admins can read any board — Viewer is not a security boundary.

External sharing

Public view links, password-protected links, and link expiration. Use a guest invite when the person needs to participate rather than just view.

SSO and provisioning

On Enterprise plans, auto-provision members through SAML and map SAML groups to roles.

Audit logs

What’s logged, where to find it, and how to use it in compliance reviews — see Security & compliance.