Workspace permissions overview

Documentation Index

Fetch the complete documentation index at: https://docs.bowerlabs.ai/llms.txt

Use this file to discover all available pages before exploring further.

Bower has two layers of permissions, and they fit together in a specific way. This page covers both layers and how they interact, so you know exactly what each role can and can’t do.

​

The two layers

Workspace roles decide what someone can do across the workspace — invite people, change billing, manage settings, edit content in general. Every workspace member has exactly one role. Per-entity privacy decides who can read or edit a specific note or collection. The default is “everyone in the workspace can see it”; you can override that on individual items. Both layers run on every request — the answer Bower gives is the most restrictive of the two.

​

Workspace roles

When you invite someone, you pick their role. Owner, Admin, Member, and Viewer are paid seats; Guest is a free seat with a per-tier cap. Permissions cascade — Owner has everything Admin has, Admin has everything Member has. ¹ Only the workspace Owner can promote another member to Owner. Admins can manage Member ↔ Admin transitions but cannot create new Owners.

​

Why these roles

• Owner (paid) — the workspace lead. Handles billing, can transfer ownership, and provides admin oversight of team work. Cannot read content marked Just me.
• Admin (paid) — manages members and settings but doesn’t control billing. Useful for delegating workspace administration to lab managers without giving up the billing relationship.
• Member (paid) — the default for invited collaborators. Can read and edit anything that’s not restricted away from them, and create new content.
• Viewer (paid) — strict read-only across the workspace. The paid seat for stakeholders where read-only must be enforced by role, not just by per-entity privacy — auditors, IRB observers, regulated reviewers.
• Guest (free) — read-only across the workspace, no seat cost. Capped by plan (Starter 1 / Pro 4 / Team 4 per paid seat). Right for external collaborators who need visibility but don’t warrant a paid seat.

Today Viewer and Guest are operationally similar — both are read-only. The role split exists to give Guest room to grow some write actions later without losing the strict read-only paid seat that compliance use cases require.

​

Paid ↔ Guest is a billing-class change

Moving a user between the paid roles (Owner / Admin / Member / Viewer) and Guest isn’t a role flip — it’s remove and re-invite. The role dropdown deliberately doesn’t offer Guest for paid members, and doesn’t offer paid roles for guests. See Invite team members for why.

​

Last-Owner protection

A workspace must always have at least one Owner. If you try to:

• Demote the only Owner to Admin (or anything else), or
• Remove the only Owner from the workspace (including leaving the workspace yourself if you’re the sole Owner),

Bower will refuse the action with a clear error message. The supported way to hand off the workspace is the Transfer ownership flow in workspace settings: it atomically promotes the new Owner and demotes the old one in one step, so the workspace always has exactly one Owner.

​

Per-entity privacy

By default, every note and collection in a workspace is visible to all members — that’s “Anyone in this workspace” mode. You can override this on individual items via the Share dialog. There are three modes: For the full Share dialog walkthrough, see Sharing notes and collections.

​

How the two layers interact

When someone tries to read a note, Bower checks both layers and returns the most restrictive answer:

• Workspace role decides if they can read content at all. Viewers and Guests can read but not edit; non-members can’t read anything.
• Entity privacy decides if they can read this specific note. A note in Only specific people mode is invisible to anyone not on the list (or who isn’t the creator or workspace Owner). A note in Just me mode is invisible to anyone except the creator and people the creator has explicitly added.

Examples:

• Workspace Member opens a default-public note → reads it (workspace role allows, entity is open).
• Workspace Member opens a Only specific people note they’re not on → 404. They don’t get to know it exists.
• Workspace Owner opens a Only specific people note → reads it (Owner has admin oversight in this mode).
• Workspace Owner opens a Just me note someone else created → 404. Owner has no oversight on Just-me content.
• Workspace Viewer or Guest opens a default-public note → reads it (the role can read, entity is open). They cannot edit (read-only role blocks).

​

Special people: creator and Owner

Two people always retain a baseline level of access:

• The entity creator — whoever made the note or collection always retains Full (Manage) access on it. You can mark your own work Only specific people without locking yourself out.
• The workspace Owner — retains access on Workspace and Only specific people entities (admin oversight). The Owner does not retain access on Just me entities — that’s the structural difference that makes “Just me” actually private.

​

Restricted content the user can’t see

When a workspace member follows a direct link to a note or collection they don’t have access to, Bower shows a calm splash page that:

• Confirms the content is private (not deleted).
• Shows the owner’s name and email so the user knows who to ask.
• Offers a Request access button that opens an email pre-filled with a polite request.

This is intentionally Notion-style: not an alarming “Access denied” but a polite handoff to the human who can grant access. If the entity actually doesn’t exist (or belongs to another workspace), Bower returns a generic “not found” instead — it never confirms the existence of an entity to someone outside the workspace.

​

Compliance: disable “Just me” for the whole workspace

For regulated industries (HIPAA, IRB-governed research, audit-everything environments), the workspace Owner can disable Just me mode entirely. When Just me is disabled in the workspace:

• Users clicking “Just me” in the Share dialog get a Only specific people entity with themselves on the list (workspace Owner still has access).
• The auto-demotion from Only specific people back to Just me doesn’t fire when the last collaborator is removed.
• The behaviour falls back to the previous Bower model — every entity is readable by the workspace Owner.

This is opt-out: by default, Just me is allowed in every workspace. Workspace Owners turn it off via workspace settings when their compliance posture demands it.

​

Audit log

Every privacy-mode change and access-list change is recorded in the audit log:

• Who made the change.
• What changed (mode flip, grant added, grant revoked).
• When it happened.
• What entity it affected.

Audit log entries reference user IDs only — they do not include emails, names, or content snippets. The entity title is captured (admin needs to see what was changed). The content body is never logged.

​

Frequently asked

Can a workspace Member create a Just-me entity? Yes. Any member of a workspace can create a note or collection and mark it Just me. The creator is the one who controls who else (if anyone) gets access. What happens to my Just-me notes when I leave a workspace? For now, they remain in the database as orphans — no one has access (not even the workspace Owner). Admin take-ownership tooling is coming in a future release. If you want to keep your work after leaving, share or export it before you go. Does the workspace Owner know I have Just-me notes? The Owner sees metadata in the audit log — that you created a note, when it was edited, when its privacy mode changed. They cannot see the title, content, tags, or any of the actual work. Can I share a Just-me note with one person privately? When you add anyone, the note is no longer Just me — Bower auto-promotes it to Only specific people and the workspace Owner regains access. There’s no “private to two people” mode. If you genuinely need a small private space that the workspace Owner can’t see, the right answer is a separate workspace. Can I lock the workspace Owner out of even Only specific people entities? No. The Owner always has access on Workspace-mode and Only-specific-people entities. They lose access only on Just me entities. This separation matches Notion’s model and reflects the practical reality that Owners need oversight of team work but shouldn’t peek into individual private notes. Can the access list be inherited? Yes. If a collection is in Only specific people mode, all notes inside it inherit that access (unless they have their own privacy settings). The Share dialog shows where access is inherited from with a clickable link, so you can navigate up and edit the source of truth.