Access Reference
The full rules of who can see what, with edge cases and scenarios.
This page is the complete reference for how Fuser decides who can see and edit a project. Most days you don't need it — the defaults work the way you'd expect, and the Sharing page covers the common cases. Reach for this page when something surprises you.
Mental Model
Seven rules cover the 80% case. Internalize these and you can predict access for almost any situation.
- Workspace Owners and Admins can edit everything in the workspace. Always. Skip the rest of these rules for them.
- Drafts are private. A Draft project is yours alone until you publish it or share it — your teammates can't even see it exists.
- Published projects open up to where they live. Publish at the workspace root → everyone in the workspace sees it. Publish in a folder → people who can see the folder see it. Publish in a team folder → the team sees it.
- Folders set the access level for everything inside them. A folder marked View gives readers read-only access; Edit gives full read/write. Projects inherit this.
- Team folders are gated by team membership. If you're not in the team, you don't see its folders or projects unless someone shares them with you.
- Sharing only adds access, never removes it. Use shares to give one person Edit on a project they otherwise couldn't touch.
- The workspace root has its own default (View or Edit), set by your workspace Admin. This is the fallback whenever a folder says Inherit.
Edge Cases
The cases below are the ones that surprise people. Each has caused real confusion — read them once and you'll save yourself a debugging session later.
Re-drafting removes others' access
Switching a Published project back to Draft removes everyone else's access immediately — including yours, in some cases. If you weren't the original creator, only the creator and workspace Admins keep Edit. Add an explicit Edit share to yourself before flipping a Published project back to Draft.
Archiving a team caps members at View
When a team is Archived, its members keep access but at View only — even on folders set to default-Edit. Non-members lose access entirely (Open teams stop being open when archived). Explicit Edit shares survive the cap and continue to work.
Private folders override their projects
A Published project inside a Private folder is still hidden from everyone except the folder creator and workspace Admins. The folder's privacy gate takes precedence over the project's visibility setting.
Folder creators don't automatically see team folders
Creating a folder in a team grants you management rights — you can rename it, change its default access, and add projects. But it doesn't grant visibility. If you later leave the team, the folder disappears from your view. To keep seeing it, get a share.
Comment access only comes from shares
The Comment access level can only be granted through a share. You can't set a folder or workspace root to default-Comment — those default to View or Edit only.
Removing a member revokes everything immediately
When you remove someone from your workspace, they lose access to every workspace project, folder, and share immediately — including projects they created in the workspace. Their personal projects (made outside any workspace) stay with them. If you re-invite them later, you'll need to re-share anything they should still see.
Open teams aren't necessarily joinable
Open means discoverable by everyone in the workspace. It does not mean public outside the workspace, and it doesn't always mean self-join is enabled. Use Closed when you want a team's work hidden from non-members.
Direct-to-team projects use the workspace root default
A project assigned to a team but not placed in any folder uses the workspace root access level, not a folder default. This sometimes surprises Admins who expect team projects to follow per-folder settings.
Personal projects are separate from your workspace
A project you created outside any workspace belongs only to you. Workspace Admins can't see or manage it. Moving it into the workspace changes its access model entirely — share it carefully if it has personal context.
Verified domains don't grant access by themselves
Verified-domain auto-join lets people sign in with a matching email and join your workspace. Until they actually accept and become a workspace Member, they have zero implicit access — only direct shares (typically by email) reach them.
Scenarios
A few common situations and what each person sees. Assume the workspace root default is Edit (the out-of-the-box default) unless noted.
| You are... | The project is... | You see... |
|---|---|---|
| The creator | A Draft, anywhere | Edit |
| A workspace Admin | Anything in the workspace | Edit |
| A team Member | Published, in your team's folder set to View | View |
| A team Member | Published, in your team's folder set to Edit | Edit |
| A workspace Member not in the team | Published, in a Closed team's folder | Nothing |
| A workspace Member not in the team | Published, in an Open team's folder | Edit (workspace root level) |
| A team Member, team Archived | Published, in a folder set to Edit | View (cap) |
| Anyone with a public link | The project has Share a Link on | View (read-only) |