Permissions & Access Control

Access has three layers:

1. Your organization role: what your account can do across the organization.
2. A board's access: who can open and edit that particular board.
3. Published access: who outside your team can view a published board.

A board can be private internally and published publicly, or org-visible and password-protected externally. Changing one layer does not change another.

Organization roles

Your org role is set when you are invited or first sign in through SSO:

Roles are permission tiers, not job descriptions. For Every Role explains how different roles use the same workflow.

Assigning admin and read-only roles is included from the Team plan. Below Team, members have the contributor role and the owner retains ownership. The Team page explains this restriction in its role controls. Roles granted before a downgrade stay in place.

Every member holds a billed seat, whatever their role — see Plans & Billing.

Board access

Each board adds its own access on top of org role. Open a board's permissions dialog to set:

General access: the board's default for everyone in the org:

The permission list: named people, added by email, each at one level:

The board creator is its owner and cannot be downgraded. Everyone else is an editor or viewer.

The settings combine additively. Anyone in the organization · viewer plus two named editors gives the org read access and those two people write access. Private removes the org-wide grant without changing named access.

Published access

Publishing is separate from internal access and controls the external read-only view.

Visibility levels

Share tokens

Published boards use share tokens in the URL. Rotate a token to invalidate old links.

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 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.

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:

1. The existing share token is replaced with a new randomly generated value.
2. The old published URL immediately stops working. Anyone using it gets a 404.
3. The new URL (with the fresh token) must be re-shared with intended viewers.
4. Internal permissions and board content are unaffected.

You can also remove the share token entirely. That 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, while the published snapshot is open to anyone.
• An org-visible board can have protected publishing. Everyone internally reads it, while external viewers need the configured share token, password, or both.
• Changing published visibility never affects who can edit the board internally.
• A read-only org role cannot be expanded by a board grant: board access decides which boards you can reach, and your org role decides what you can do there.

Verify your permissions setup

Verify the setup:

• 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 are not 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 when one is configured
• Rotating a share token invalidates the old published URL

What's next