Permissions.

Six permission tiers cover everything from no access to full administrative control.

The six permission tiers

  • No access — cannot open the project.
  • View — can read everything (notebooks, dashboards, documents) but cannot edit or run anything.
  • Comment — view + can leave comments on blocks.
  • Execute — can run blocks and use the agent, but cannot save edits.
  • Edit — can change content, add/remove blocks, run code, and save changes.
  • Full access — edit + manage sharing, members, and permissions. The publisher always starts at full access.

Tiers cascade across all notebooks and dashboards in a project — there's no per-notebook permission. Want to share one notebook but not the rest? Split it into its own project.

The project members modal showing the publisher and several members with permission-tier pills./docs-images/collaboration/members-modal.png
Project Members — change tiers, invite, remove, manage sharing.

Project vs. published

Two axes, set independently:

  • Project membership — per-person permission tier for opening the project in Orchid.
  • Publish visibility — who can read the share viewer at <slug>.orchidide.com. One of public, link-only, or team.

A project can have members at the View tier and be publicly published. A project can be team-only and still have an external collaborator with Edit access. These are independent toggles.

Project: q1-review
Members:
  alice    Full access  (published this project)
  bob      Edit
  chris    Comment
  dee      View

Publish: public at q1-review.orchidide.com
  → anyone with the URL can see the rendered output
  → only alice/bob/chris/dee can open it in Orchid

Inviting people

Open Members from the project menu. Type an email; pick a tier. They get an invitation email with a link that completes when they sign in (or sign up). Their tier is set in the invite — change it on the Members page later if needed.

Pending invites show up in the Members list with an "Invited" badge until accepted. Revoke a pending invite by clicking the X — the link stops working immediately.

Revoking access

Three ways to remove someone:

  • Change tier to No access — they lose project access immediately. Their previous comments and contributions stay attributed to their account.
  • Remove from project — same effect; the row leaves the Members list.
  • Unpublish — kills external visibility for everyone, regardless of tier.

Access revocation propagates within seconds. If they have the project open when you revoke, the next save attempt fails and the notebook becomes read-only.

Warning

Revoking an Edit-tier member doesn't roll back their previous edits — those stayed in the file with their attribution. Use the version history to revert specific changes if needed.

Project ownership

The first person to publish a project owns the cloud row — they start at Full access and can grant Full access to others. There is no single "Owner" role; multiple members can hold Full access on the same project.

Whoever has Full access can change any other member's tier, including their own.

Connections & credentials

Permissions cover the project content. Database connections are scoped per user per machine — even a Full-access member doesn't inherit other members' credentials. Each collaborator supplies their own connection settings locally.

The exception is organization and team shared connections: an organization can store one service-account credential in an encrypted vault and let a team query through it without anyone seeing the password. See Secrets & env vars for how that vault works.

Tip

For team projects with a shared warehouse, configure a service-account connection locally and use the same profile name across machines (e.g. warehouse). Cells reference profiles by name, so the notebook works for everyone even though each person's credentials are private.

Back to Collaboration overview, or read about real-time editing, comments, and publishing.