Last updated July 24, 2026
Permissions & Access Control
Access works in three layers, and they're independent of each other:
- Your organization role — how far the org trusts your account overall.
- A board's access — who can open and edit that particular board.
- Published access — who outside your team can view a board you've published.
A board can be private internally and published publicly, or open to the whole org and password-protected outside it. Nothing about one layer decides another.
Organization roles
Your org role is set when you're invited (or when you first sign in through SSO) and travels with you everywhere in the product:
| Role | What it grants |
|---|---|
| Read-only | See everything shared with you, change nothing. |
| Contributor | The working role — author and edit boards, specs, intents, and insights. |
| Admin | Everything above, plus members, integrations, and org settings. |
| Owner | Everything above; the account that owns the organization and can't be locked out. |
Roles are trust tiers, not job descriptions — an analyst and a principal engineer are both contributors with identical authority. For Every Role covers why that's deliberate.
Board access
On top of your org role, each board decides who reaches it. Open a board's permissions dialog and you set two things.
General access — the board's default for everyone in the org:
| Setting | Who can reach it |
|---|---|
| Private | Only the people named in the permission list below |
| Anyone in the organization | Every org member, at the level you pick — viewer or editor |
The permission list — named people, added by email, each at one level:
| Level | Can view | Can edit | Can manage permissions |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Editor | Yes | Yes | No |
| Viewer | Yes | No | No |
The person who created the board is its owner, and can't be downgraded. Everyone else is added as an editor or a viewer.
The two combine additively: a board set to Anyone in the organization · viewer with two named editors gives the whole org read access and those two write access. Setting a board to Private takes the org-wide grant away without touching the named list.
Published access
Publishing is a separate decision again — it controls who can see a board from outside your team, through the portal, and owes nothing to the two layers above.
Visibility levels
| Visibility | Behavior |
|---|---|
| Public | Anyone with the URL can view the published board |
| Unlisted | Not indexed or discoverable, but anyone with the direct link can view it |
| Protected | Requires a password to view — visitors must enter it before seeing the board |
Share tokens
Published boards use share tokens for link-based access. The token is embedded in the published URL to identify which board to serve. Share tokens can be rotated if a link needs to be invalidated — generating a new token makes the old URL stop working.
Password protection
Protected boards can require a password:
- Passwords must be 4–128 characters
- The password is hashed server-side before storage — the plaintext is never saved
- Remove the password to keep the protected visibility but allow token-only access
- Password protection only applies when visibility is set to Protected
Share token rotation
Share tokens control link-based access to published boards.
When to rotate a token:
- A published link was shared with someone who should no longer have access
- You suspect the URL has been leaked beyond the intended audience
- As a periodic security measure for sensitive boards
What happens when you rotate:
- The existing share token is replaced with a new randomly generated value.
- The old published URL immediately stops working — anyone using it gets a 404.
- The new URL (with the fresh token) must be re-shared with intended viewers.
- Internal permissions and board content are unaffected.
You can also remove the share token entirely — that effectively unpublishes the board by removing its portal URL.
How the layers work together
- A private board can still be published publicly — your team restricts who edits it, the published snapshot is open to anyone.
- An org-visible board can have protected publishing — everyone internally reads it, external viewers need a password.
- Changing published visibility never affects who can edit the board internally.
- A read-only org role can't be widened by a board grant: board access decides which boards you reach, your org role decides what you can do when you get there.
The short version: your org role controls the workspace experience (editing, collaborating), board access controls which boards, and published access controls the portal experience (the read-only snapshot).
Verify your permissions setup
Use this checklist to confirm everything is wired up correctly:
- Board owner can view, edit, and manage permissions
- Added editors can view and edit but not change permissions
- Added viewers can view but not edit
- Private boards are not visible to org members who aren't explicitly added
- A board set to "Anyone in the organization" is reachable by all org members at the level you chose
- Published boards with Public visibility are accessible without authentication
- Published boards with Protected visibility prompt for a password
- Rotating a share token invalidates the old published URL