Access and sharing
Visibility levels, who can edit vs. view, per-person invites, and passwords.
Every page and presentation has an access model with two independent parts: a visibility level, which decides who can open the link by default, and invites, which grant specific people access on top of that, regardless of visibility. Access is decided on the server on every read; nothing about it is trusted from the client.
Visibility levels
These are the levels available from the Share dialog's "General access" section:
| Label in the app | Who can open the link |
|---|---|
| Just me | Only you, plus anyone you invite below. |
Everyone at <company> | Any member of your workspace. |
| Anyone with the link | No sign-in needed. |
| Anyone with the link + password | The link, plus a password you set. |
A signed-in colleague whose verified email domain matches your workspace's domain can still view a workspace-visibility page even without full workspace membership (for example, if their active account is a different org), but view-only: commenting and editing still require full membership.
Passwords are hashed (argon2) and rate-limited, and workspace members always bypass the password gate on their own workspace's pages.
Legacy 'invited' visibility
Pages created before per-person invites existed may still carry the legacy
invited visibility value. It is no longer offered as a selectable option;
the Share dialog shows such a page as "Just me" (owner plus whoever is
explicitly invited).
Editing vs. viewing
Editing is decoupled from visibility. A workspace-visibility page or presentation is collaborative by default: any member of the workspace can edit its content, not just view it. Management actions, changing visibility, deleting, and managing sharing, are narrower: only the owner or a workspace admin can do those, on any visibility level.
So there are four distinct rights, from narrowest to broadest:
- View: can open the link.
- Comment: members and signed-in invited guests can comment; on a public or password-protected page, anonymous visitors can comment too (optionally under a name).
- Edit: can change the content (owner, workspace admin, a workspace member on a workspace-visibility page, or an invited editor).
- Manage: can change visibility, delete, and manage sharing (owner or workspace admin only).
Per-person invites
Invites are an independent layer, honored under every visibility level: someone invited by email gets at least view and comment access, on top of whatever the visibility already grants, without you having to open the page to everyone. An invite never grants management rights.
Invite someone from the Share dialog's "Invite specific people" section by email or by picking a teammate, then choose their role:
- Can view: view and comment.
- Can edit: view, comment, and edit content.
This works the same way for pages and for presentations (decks): both have their own invites layer, managed from the same kind of Share dialog, gated to the owner or a workspace admin.
Inviting specific people is a web-dashboard action today; there isn't yet an MCP tool to add an invite. An AI client can create and edit pages and decks under whatever visibility and edit rights you've already granted it, but a human needs to open the Share dialog to invite someone new.
See also
- Pages for
visibilityandpasswordoncreate_pageandupdate_page. - Slide decks for presentation-specific sharing.