Access
Private by default, explicit sharing with people, groups or a workspace, and deliberate public links.
New documents, databases and forms start Restricted. Only the owner and people with an explicit or inherited permission can access them. Signing in proves who you are; membership or an approved email domain alone never grants access to a document.
Restricted (default)
visibility: "restricted" requires sign-in and checks the same permissions as the app and MCP tools. With no sharing on a personal document or its folder chain, only the owner has access. Choose Access in the document inspector to add a person, group or the whole workspace.
| Audience | Who can access |
|---|---|
| Private | The owner; no direct or inherited sharing |
| Selected people/groups | The owner and recipients of direct or inherited grants |
| Everyone in this workspace | Active workspace members, through an explicit workspace grant |
A grant gives view, comment or edit. Direct people and workspace grants are available on every plan; groups require Team or above. Commenting itself remains a paid-plan feature. Workspace administrators do not automatically gain access to other members' personal documents. Managers can administer shared spaces and their contents.
A document in a shared space inherits that space's audience and any folder restrictions. The access panel shows inherited permissions. Removing the last grant never turns a restricted item into a workspace-wide share. A restricted folder in a shared space keeps its own empty audience until a manager explicitly selects Use parent permissions instead.
A viewer signs in on Fermium and is redirected back to the document through a one-time handoff code. The content host rechecks access on each request. The app and content hosts use separate cookies. Restricted responses use Cache-Control: private, no-store.
Request access to a locked link
Signed-in members of the document's workspace can select Request view access and add an optional message. The locked page keeps checking while it is visible and opens the document automatically after approval. Viewing a locked link does not send a request by itself.
The personal document's owner, or the managers of its shared space, receive a Fermium notification and an email when email delivery is configured. Open the document's Access panel to approve or deny. Approval grants view access to that document only. It does not share its folder, other files or a form's separate response database.
The email also includes approve, deny and manage-permissions links. A review link opens a confirmation screen, expires 30 days after the request, and can decide the request once. It stops authorizing changes if the manager loses permission or the document's sharing context changes. The requester receives the decision in Fermium and by email when available.
Pending requests expire after 30 days. A declined request can be sent again after 24 hours. Revoking an approved grant removes access immediately; replaying the old email link cannot restore it. Requests currently support existing workspace members. If you use multiple accounts, sign in with the account in the document's workspace.
Agents can request, poll and review access through the MCP tools, using the connected identity.
Workspace
visibility: "workspace" is the legacy sign-in setting. It now requires the same explicit or inherited permissions as Restricted. An empty access list no longer admits all workspace members or viewer-domain accounts. Use restricted for new content; to share with everyone, add a workspace grant.
Existing workspace documents with private listings and no sharing become owner-only. Existing deliberate team listings and shared spaces keep their former audiences as visible, explicit grants. Existing public and password links retain their access mode.
Anyone with the link
Choose visibility: "unlisted" to deliberately allow anyone holding the link to open it. This is useful for public pages and client questionnaires that should not require a Fermium account. The URL has a random 128-bit slug and is not listed publicly. Forwarding the URL forwards access.
Adding a group grant to an unlisted document does not close its public link. Select Restricted if the link should require the chosen audience. The access panel calls out externally accessible links.
Password
Choose visibility: "password" and provide a password to allow readers holding both the URL and password. The browser uses HTTP Basic authentication; passwords are hashed and never returned by the API. Password links do not require workspace membership.
For large uploads, upload as Restricted, then use set_visibility to set a password. Restricted and password links do not expose document content to chat preview crawlers.
Listing and sharing
listing controls placement, never authorization. A team listing does not grant access. Only recipients who already have permission can see an item in shared listings, search, stars, exports or MCP results. A private listing does not cancel a grant or close a public link.
Use share_doc, share_folder or share_root to grant access. Use list_access, list_folder_access or list_root_access to inspect it. Moving or changing visibility keeps the same URL.
Forms and databases
Form recipients can submit and resume their own response without receiving database read access. Share the form and the response database separately. Queries, charts, exports and MCP polling require access to the database. Notifications and scoped webhooks recheck their acting identity's access before delivery.
Enterprise network restrictions also apply to Restricted and legacy Workspace links.