Dokki decides whether you can open or change something by looking at four things together: whether the resource is public, a direct role on that resource, your workspace role, and whether the resource is private. This page explains how those combine, so you can predict the answer instead of testing it. It does not cover organization-wide policy or plan limits; those are on their own pages.
The four inputs
Input | Where it is set | Who can change it |
|---|---|---|
Workspace role | Workspace members list | Workspace admins |
Direct role on one resource | The resource's share dialog | The resource creator and admins |
Private flag on one resource | The resource's sharing settings | The resource creator and admins |
Public access | The published site | Admins and editors |
Workspace roles
Capability | Viewer | Editor | Admin |
|---|---|---|---|
View normal workspace resources | Yes | Yes | Yes |
Edit normal workspace resources | No | Yes | Yes |
Create and manage workspace tags | No | Yes | Yes |
Publish resources to a public site | No | Yes | Yes |
Invite and remove members | No | No | Yes |
Change workspace settings | No | No | Yes |
Manage shared pins | No | No | Yes |
A workspace role is the baseline for everything in that workspace. Some older workspaces may contain a manager role; Dokki treats it as admin-equivalent.
A role on one resource
When one person needs access different from their workspace baseline, share the resource with them directly. Direct roles are Viewer, Commenter, Editor, and Admin. The person who created the resource is also an owner for permission purposes.
A direct role adds access; it does not take the baseline away. Giving an Editor a Viewer role on one resource does not stop them editing it through their workspace role. When a smaller audience must be enforced, make the resource private rather than relying on a direct role.
Private resources
Workspace membership alone does not reveal a private resource. It stays available to its creator, to people with a direct role on it, to workspace admins, and to people whose access request has been approved.
Sharing is not publishing
Sharing | Publishing | |
|---|---|---|
Who can see it | The people you name, or anyone with the link if you open it | Anyone on the public site |
Who can set it | The resource creator, and admins | Admins and editors |
What it is for | Review, work in progress, named readers | Finished pages meant for the outside world |
When material is still under review or meant for named people only, share it. Publishing puts the page on a public site.
Worked examples
Situation | Can you open it? | Why |
|---|---|---|
Viewer, ordinary resource | Yes, read only | The workspace baseline grants viewing |
Editor, private resource, no direct role, not an admin | No | Membership alone does not reveal a private resource |
Viewer with a direct Editor role on one resource | Yes, and you can edit that resource | A direct role adds access beyond the baseline |
Someone outside the workspace with the public link | Yes | The resource is published |
When you cannot open something
Check whether the resource is private. A private resource does not appear to the wider workspace.
Check your workspace role, then ask whether you hold a direct role on that resource.
If you need access, request it from the resource creator or a workspace admin. An approved request is one of the ways a private resource becomes available.
Do not assume that a link from a colleague carries their permissions. Access follows your account.
To change who can do what, see Members & Roles. For the difference between a link and a public page, see Sharing & Public Access.
Last verified: 2026-10-27