Skip to content

Permissions

CardBoard authorizes in two layers: the organization (workspace) and the board. Card actions inherit from the board — if you can update a board, you can edit its cards. There’s no separate card-level permission.

This is non-obvious from the matrix alone: a guest with the board Editor role can edit cards — but gets a 403 on a tracker-linked card. State it explicitly when onboarding guests.

The same member-identity rule covers directing MCP agents: because an agent acts in your name, a guest can’t drive one — only members can.

There are four tiers for permission purposes: Owner (billing), Admin, Member, Guest.

ActionWho
View organizationMember/Admin (guests denied)
Create boardMember/Admin, within capacity
Use integrationsMember (not guest); available on every plan, including Free
View guestsOrg admin only
Manage members / settings / transfer / reportsAdmin or Owner
Manage billing, change plan, destroy orgOwner only

Board collaboration roles are Manager, Editor, Viewer, with workspace-admin override (an admin is always a manager).

ActionWho
View boardManager / Editor / Viewer, or guest with read token
Edit cards, dividers, outcomes, stickersManager / Editor
Edit a tracker-linked cardManager / Editor and workspace member (billing active)
Manage collaborators / share / change trackerManager (or workspace admin)
Delete boardManager or org admin — denied on Free plan
ExportMember (not guest)
Recover a deleted boardManager or admin

Workspace admin always wins (implicitly a manager on every board). An explicit board role overrides the workspace-member default. Guests get only the board roles they’re explicitly granted. For the access model in practice, see Workspaces & access.