Permissions & Access Control

Three layers decide who can do what with a board:

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.

Each layer is independent: changing one doesn't change another.

Organization roles

You get your org role when someone invites you, or when you first sign in through SSO:

Changed 16 October 2026: the roles read Editor and Viewer.

A role is a permission tier and says nothing about a person's job. For Every Role explains how different roles use the same workflow.

The Team page

What the portal's Team page shows depends on your role:

• Owners and admins see every member with their role and status, pending invitations included, and the seat and viewer counts. They invite members and change roles there, and suspend or remove members.
• Editors and viewers see Your access: their own role, and the owner and admins who can change it, each with an email address to write to. No other member is listed.

Organization settings → Access follows the same rule. Owners and admins see every member with their role and status. Everyone else sees Your role and the owner and admins under Who manages your organization.

Locked controls

A control your role can't use stays where it is and wears a small lock naming the role that can. An editor sees Admin on New workspace, and everyone but the board's owner sees Board owner on Publish to web….

Selecting a locked control opens a short note on what the action is and who can do it. Its See who can help button leads to Organization settings → Access, which names your organization's owner and admins. Nothing is sent to the server. A crown instead of a lock means the plan, not your role, is what's missing; see Plans & Billing.

A viewer sees no locks. Controls a viewer can never use are left off their screens. A viewer sees the boards, work items, changes and chat, and can move the work items assigned to them. Settings, sources, playbooks and the Skills screen stay out of a viewer's navigation.

The same note opens if the server refuses an action your screen still offered, which happens when your role changed while you were working. A viewer's note has no See who can help button.

You can assign the Editor and Viewer roles on every plan, and the Admin role from the Team plan up. The owner keeps ownership on every plan. If you downgrade, roles you granted before stay in place.

A seat is a member who can write: editors and admins hold a billed seat, viewers never do. See Plans & Billing.

The code plugin and your role

Any member, viewers included, can connect the code plugin to an app board that already exists and push from their repository. They can also pull, claim and resolve the work items assigned to them. The credential belongs to the board's binding, not to a seat. Creating the app board or connecting a new source is an editor's step, so the sign-in page doesn't offer Make it an app to a viewer.

A credential stops working when the member who created it is suspended or leaves the organization. The push says so, and an admin or editor signs in again to mint a new one.

Connectors, automations and reporting

Your org role also decides what you can do with connectors, automations and workspace reporting:

A connection to your own account is yours alone. Every read and every issue you send goes through it, and nobody else reads through it. Viewers don't see Share to Slack… or Send to Jira….

Sentry insights also need Pro or above. After a downgrade below Pro, automations stop posting and Sentry insights stop arriving; both stay set up and start again when you upgrade.

Board access

Each board adds its own access on top of your org role. In a board's permissions dialog you set two things.

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

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

Whoever creates a board is its owner, and nobody can downgrade them. Anyone else you name gets one of the three levels, Owner included.

The two settings add together. Anyone in the organization · Can view plus two named editors gives the org read access and those two people write access. Switching to Private removes the org-wide grant and leaves named access as it was.

Published access

Published access controls the read-only view people outside your team see.

Visibility levels

Share tokens

A published board's URL carries a share token. Rotate the token to invalidate old links.

Password protection

A Protected board can require a password:

• A password must be 4–128 characters
• We hash the password on the server before storing it and never save the plaintext
• To keep Protected visibility but allow access with the token alone, remove the password
• Password protection applies only when visibility is set to Protected

Share token rotation

When to rotate a token:

• You shared a published link with someone who should no longer have access
• You suspect the URL has leaked beyond the intended audience
• On a regular schedule, for sensitive boards

What happens when you rotate:

1. A new, randomly generated value replaces the existing share token.
2. The old published URL stops working immediately, and anyone using it gets a 404.
3. You share the new URL with the viewers you intend.
4. Internal permissions and board content don't change.

You can also remove the share token entirely. Removing it takes away the board's portal URL, which unpublishes the board.

How the layers work together

• A private board can still be published publicly. Your team restricts who edits it, and anyone can open the published snapshot.
• An org-visible board can have protected publishing. Everyone inside the organization reads it, and external viewers need the configured share token, password, or both.
• Changing published visibility never affects who can edit the board internally.
• A board grant can't expand a Viewer org role. Board access decides which boards you can reach, and your org role decides what you can do there. The board level Viewer and the org role Viewer agree on the map: both read it, and neither edits it.

Verify your permissions setup

Check each item after you set a board's access:

• The board owner can view, edit, and manage permissions
• Added editors can view and edit but can't change permissions
• Added viewers can view but can't edit
• Org members you haven't added can't see a private board
• Every org member reaches a board set to "Anyone in the organization" at the level you chose
• Anyone can open a published board with Public visibility without signing in
• 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