Last updated April 21, 2026
Permissions & Access Control
ContextDX has two distinct permission layers: internal permissions (who on your team can see and edit boards) and published access (who outside your team can view published boards). They're independent — a board can be restricted internally but published publicly, or vice versa.
Permission layers
Permission levels
Every board has an owner and can have additional collaborators with specific roles.
| Level | Can view | Can edit | Can manage permissions |
|---|---|---|---|
| Owner | Yes | Yes | Yes |
| Editor | Yes | Yes | No |
| Viewer | Yes | No | No |
The owner is always the person who created the board — you can add other editors and viewers, but you can't downgrade the owner.
Each additional user you grant access to is identified by their email, with a role of either editor or viewer.
General access
Controls organization-wide visibility for a board:
| Setting | Who can see it |
|---|---|
| Organization | Anyone in your organization can view the board |
| Private | Only users explicitly added to the permissions list |
When set to Organization, all org members get implicit view access. You still need to add people as editors if you want them to make changes.
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 they work together
Internal permissions and published access are independent controls:
- A private board (internal) can still be published publicly — your team restricts who edits it, but the published snapshot is available to anyone
- An organization-visible board can have protected publishing — everyone internally can see it, but external viewers need a password
- Changing published visibility doesn't affect who can edit the board internally
Think of it this way: internal permissions control the workspace experience (editing, collaborating). Published access controls the portal experience (viewing the read-only published 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
- Organization-visible boards are viewable by all org members
- 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