Members and roles

Members are the accounts attached to a workspace. Each has a workspace role, and each document has one owner. On Team and above, groups let you grant access to Developers, Leadership and other teams. Workspace membership alone does not open private files.

Roles

What each role may do:

Workspace-level settings such as billing and domains are not role-restricted today; keep the member list to people you trust with them.

The local-review AI credits balance is separate: only owners and admins can enable hosted usage, buy credits or configure automatic top-up. See AI credits.

Auditor

The auditor role supports independent review. Owners can assign it to a member; invitations can also use this role. An Auditor can inspect workspace audit events and review Agent tool calls: approve or reject a pending action, or mark an allowed flagged action as reviewed. Existing restrictions on file viewer activity still apply.

Auditor does not grant Agent connection management, workspace policy administration, credential access or another person's full tool result. An independent-approver rule applies to Auditors as well as admins: the role cannot approve its own request when workspace policy requires someone else. See Audit log.

The members list

GET /api/members returns every member with email, role, when they joined, whether the account is disabled, the time of their last sign-in, and whether they sign in through SSO or were provisioned by SCIM. It also returns the plan's member cap, the number of pending invites and the seats left. Any member can read it.

In the app, Settings → People & teams provides Members, Invitations, Groups and Directory sync. Search members by email, inspect their group badges, invite people, change roles or transfer ownership. Owners and admins manage groups with member search, add/remove and bulk actions, descriptions, pending invitations, accessible resource grants and recent changes.

How people become members

• The person who signed in first and got the workspace as their personal one becomes its owner.
• Anyone who signs in with an email on one of the workspace's viewer domains, while the workspace is on a paid plan and under its member cap. See Personal and company workspaces.
• Anyone who accepts an invite.
• Anyone who signs in through the workspace's single sign-on, or is provisioned by SCIM on Enterprise.

Invites

An owner or admin invites by email with a role of admin or member (POST /api/invites with {"email": ..., "role": ...}; ownership is transferred, not invited). Choose native groups in the invitation form, or pass group_ids to the API. These assignments stay pending and grant no access until acceptance. Acceptance rechecks the inviter, group source, plan, seats and exact account email. The invite is a link of the form https://fermium.app/u/invite/<token>. It is emailed to the address, and the link is also returned in the API response so you can send it yourself.

• The link is valid for 14 days and only works when the person signs in with the invited address. Signing in with a different account shows a mismatch message and leaves the invite open.
• A pending invite reserves a seat: members plus pending invites may not exceed the plan's cap. An invite that would go over is refused with a 402 that states the numbers.
• One open invite per address; inviting a current member is refused.
• Accepting moves the person into the workspace even if their email domain is not one of its viewer domains. That is what invites are for: contractors, a subsidiary, an agency.
• If they are not signed in when they click, they sign in with Google first and the invite is applied before a personal workspace would be created.
• GET /api/invites lists open invites, group assignments and email delivery status, without reusable tokens. POST /api/invites/{id}/resend rotates the link and queues a new email. PATCH /api/invites/{id}/groups updates pending assignments. DELETE /api/invites/{id} revokes one. Mail is delivered through a durable retry queue.

Removing a member

DELETE /api/members/{user_id}, by an owner or admin (only an owner can remove another owner, and the last owner cannot be removed). Removal revokes existing browser and content-viewer sessions, API/MCP access and refresh tokens, remembered MCP consent, and Slack AI authorization. Pending authorization codes, preview/upload tickets and identity-bound form sessions also stop working. Workspace and group access ends on subsequent requests. Direct grants and outstanding invitations are cleared, and company SSO cannot automatically re-enroll the person. Rejoining requires a fresh invitation or administrator provisioning; old credentials and direct grants remain invalid even after rejoining.

The person is not deleted: they are moved to a fresh personal workspace on the Free plan and keep every document in their My documents, with the same URLs. Move company files into a shared folder before removal if they must remain with the company. Removing a member cannot retract files already downloaded or revoke access to public links and known shared passwords.

SCIM deactivation also revokes credentials and disables the account. Reactivation requires fresh authentication and agent authorization. Ordinary workspace changes invalidate credentials issued for the previous workspace, so existing agents cannot silently start operating in another workspace.

Documents in General and in shared roots stay. A document that was published into, or moved into, a root belongs to the root, not to its author: it stays where it is, with its URL, its versions and the author recorded on each version, and the root's editors keep running it. It keeps counting against this workspace's storage. The removed person can no longer open it from the app or take it back; an unlisted or password link they hold keeps working, a Restricted one no longer opens for them. If something in a root should leave with them, move it back to their My documents before removing them. You cannot remove yourself; transfer ownership first if you are the owner.

Roles and ownership transfer

An owner changes roles with PATCH /api/members/{user_id} and {"role": "admin"} (or member, or owner). A workspace can have more than one owner. Demoting the last owner is refused.

POST /api/members/transfer with {"user_id": ...} makes that member the owner and turns you into an admin. Do this before deleting your account if you own a workspace with other members; account deletion is refused otherwise.

Member limits

When a company workspace is at its cap, a new colleague who signs in gets a personal workspace instead of joining, an invite is refused with a 402, an SSO sign-in for a new account is refused with a message naming the plan, and SCIM provisioning answers 409. Raise the plan and they can be moved in.

Groups

On Team and above, a group is a named set of members: design, oncall, contractors. Groups exist so that sharing a document with a team is one grant instead of eight.

• Owners and admins create, rename and delete groups and add or remove members; every member can list them (GET /api/groups, or list_groups from an agent). A group's name gives it a slug, Account Team becomes account-team, and the slug is what grants refer to. Renaming preserves this handle and all grants.
• Only current members of the workspace can be in a group. Someone removed from the workspace leaves its groups.
• Deleting a group removes every grant that named it.
• On Enterprise, groups can also be pushed from your identity provider through SCIM; those show source: scim.

Access levels

Restricted links require a signed-in identity with explicit or inherited access. Grants share an item with people or the workspace on every plan; group grants require Team or above. Public/password links are separate external sharing choices.

A grant gives a subject a level on a document or on a folder:

• Subjects: one person (user:<email>), a group (group:<slug>), or the whole workspace (workspace).
• Levels, in order: view < comment < edit. The owner always has edit. Everyone else has the highest level of every grant that names them, one of their groups, or the workspace, across the document and the folders above it.
• A document grant is set by the document's owner or by a workspace owner or admin: share_doc(doc_id, subject, level) or POST /api/docs/{id}/access.
• A folder grant is set by the folder's owner only (folders are per account) and applies to every document of theirs at or under that path: POST /api/folders/access?path=Customers/Acme. The root cannot be shared. On a document, inherited folder grants show inherited: true and can only be removed from the folder.
• list_access(doc_id) or GET /api/docs/{id}/access shows the owner, every effective grant, narrowed, and my_level. unshare_doc or DELETE /api/access/{grant_id} removes a grant; the document or folder owner, the grant's creator, or a workspace admin may do that.

Everything above is about documents in someone's My documents, where the owner is a person. Documents in General and in shared roots take their levels from the root's access list and the folder lists inside it, set by workspace owners and admins; there, everyone with edit can also move a document, change its visibility, listing, retention and alias, and delete it, and grants on a single document are made by the root's managers. See Roots and folders.

What grants do to opening a document

• Restricted and legacy Workspace visibility. Only the owner and recipients with at least view may open the document. With no grants or inherited access, a personal document is owner-only. A workspace membership or viewer-domain email never substitutes for a grant.
• Unlisted and password visibility. Grants do not change who can open the link; the link or the password is the credential. Grants still decide who may comment on and edit the document from the app or an agent.
• Sharing never makes a link more public than its visibility. It does not turn an unlisted link into a public one, and it does not bypass a password.

The file browser shows team-listed documents and, in addition, every document shared with you through a grant, whether or not it is team-listed. Both are tinted as shared and carry the owner; the Shared with me filter shows only them.

What each level allows

An editor who tries an owner-only change gets a 403 naming the rule (only the document owner can change its visibility). Someone with no grant gets a 404, so the document's existence is not confirmed.

Comments

Comments are available on every paid plan (Team and above). A comment hangs off a document, optionally pinned to a file (path, such as source.md or index.html) and an anchor (a heading id or a line number), and is either open or resolved.

Who may comment:

• the owner;
• anyone with comment or edit access through a grant;
• membership and listing alone do not grant comment access.

Anyone who may comment may resolve or reopen a comment. Only the author edits a comment's text. The author or the document's owner can delete one. Bodies are limited to 8,000 characters.

Agents read comments back with list_comments(doc_id) (open ones by default; include_resolved: true for all), leave them with add_comment, and close them with resolve_comment. Agents are told to treat open comments as the feedback queue for the next update, and to resolve a comment after publishing the fix, not before. REST: GET and POST /api/docs/{id}/comments, PATCH and DELETE /api/comments/{id}.

Google Workspace groups

Team and above can connect Google Workspace under Directory sync. An administrator selects Import once to create an editable native group, or Keep synced to use Google as the membership source. Synced groups cannot be edited through the native UI, REST or MCP group operations.

Sync checks direct members about every five minutes. Existing verified accounts in this Fermium workspace are matched by primary email and bound to Google's immutable user ID. External and suspended Google users grant no access; people without a matching Fermium identity remain pending. Nested groups are not expanded. No invitations or file grants are created by connecting Google.

Incomplete or failed syncs preserve the last complete membership snapshot. Access through synced groups pauses after one hour without a successful sync, or immediately when disconnected. Other explicit access paths still apply. Enterprise can enforce Google-managed groups only after a healthy sync and deliberate retirement or migration of native/SCIM groups.

Your Fermium operator must configure the Google Directory OAuth client before connection is available. Google may require administrator approval or app verification.

Viewers and permissions

A viewer domain controls sign-in eligibility; it does not grant document access. Restricted and legacy workspace links require a signed-in identity with current permission. Public unlisted and password links are explicit publication choices. See Access.

Provisioning from your identity provider

Enterprise workspaces can create, update and deactivate members and push groups from Microsoft Entra ID, Okta or any SCIM 2.0 client. See SSO and SCIM.