Summary and recommendation
Observable user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Observable is a collaborative data notebook platform built around workspaces.
User management is handled entirely through the admin UI at Workspace Settings → Members, with no automated provisioning available.
Every app in your stack that lacks SCIM requires this kind of manual oversight, and Observable is no exception.
Quick facts
| Admin console path | Workspace Settings → Members |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | N/A |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Owner | Full administrative control: manage members, billing, workspace settings, transfer ownership, delete workspace, manage all notebooks. | All plans (one Owner per workspace) | Counts as a paid seat on Pro and above | Ownership can be transferred to another member but there can only be one Owner at a time. | |
| Editor | Create, edit, and publish notebooks within the workspace; collaborate on shared notebooks. | Cannot manage billing, change workspace settings, or manage other members. | Pro plan or higher for paid Editor seats | $9/user/month on Pro plan; custom pricing on Business/Enterprise | On the free Starter plan, the number of Editor seats is limited. |
| Viewer | View and comment on notebooks shared with them; cannot edit notebooks. | Cannot create or edit notebooks, manage workspace settings, or manage members. | Available on Pro and higher plans | Viewer seats may be available at reduced or no additional cost depending on plan; verify current pricing at observablehq.com/pricing | Viewer access scope depends on notebook sharing settings set by Editors/Owners. |
Permission model
- Model type: role-based
- Description: Observable uses a fixed set of workspace-level roles (Owner, Editor, Viewer). Permissions are assigned per role and are not individually configurable. Notebook-level sharing controls (private, workspace, public) layer on top of workspace roles.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Workspace-level roles with notebook-level visibility controls (private, workspace-visible, public). No field-level or resource-level custom permission sets.
How to add users
- Navigate to your workspace URL (e.g., observablehq.com/@your-workspace).
- Open Workspace Settings (gear icon or Settings link).
- Select the Members tab.
- Click 'Invite members'.
- Enter the invitee's email address.
- Select the role to assign (Editor or Viewer).
- Send the invitation; the invitee receives an email to accept and join.
Required fields: Email address of the invitee, Role selection (Editor or Viewer)
Watch out for:
- Invitees must have or create an Observable account to accept the invitation.
- Seat limits apply based on the current plan; adding Editors beyond the plan limit may require a plan upgrade.
- Invitations expire if not accepted; a new invitation must be sent.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | No | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Observable's documentation describes removing a member from a workspace. Whether this constitutes a full account deletion or a workspace-level removal (deactivation) is not explicitly distinguished in publicly available official docs. Removing a member revokes their workspace access; their Observable account itself is not necessarily deleted.
- Navigate to Workspace Settings → Members.
- Locate the member to remove.
- Click the options menu (ellipsis or similar control) next to the member's name.
- Select 'Remove from workspace' or equivalent option.
- Confirm the removal.
| Data impact | Behavior |
|---|---|
| Owned records | Notebooks created by the removed member within the workspace remain in the workspace; ownership transfer behavior is not explicitly documented in publicly available official sources. |
| Shared content | Notebooks previously shared with the removed member that are workspace-visible remain accessible to remaining workspace members. |
| Integrations | Not documented |
| License freed | Removing an Editor seat frees that seat, which may reduce the billable seat count depending on billing cycle and plan terms. |
Watch out for:
- Removing a member does not delete their Observable account; they retain access to their personal notebooks and any public content.
- Billing cycle timing for seat release is not explicitly documented in publicly available official sources; verify with Observable support.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Editor seat | Ability to create, edit, and publish notebooks within the workspace. | $9/user/month on Pro plan; custom on Business/Enterprise |
| Viewer seat | Read-only access to notebooks shared with them. | Pricing varies by plan; check observablehq.com/pricing for current rates |
- Where to check usage: Workspace Settings → Members (shows current member list and roles)
- How to identify unused seats: No documented automated inactive-seat detection; admins must manually review the Members list and cross-reference last activity, which is not surfaced in the UI per publicly available documentation.
- Billing notes: Observable bills per Editor seat on the Pro plan at $9/user/month. Business and Enterprise pricing is custom. Starter plan is free with limited seats and features. Billing details are managed under Workspace Settings → Billing.
The cost of manual management
Observable uses a fixed role model - Owner, Editor, and Viewer - with no custom roles or granular permission sets. Adding a user means navigating to the Members tab, entering an email, and selecting a role; the invitee must accept via email before access is granted.
Invitations expire if not accepted, requiring a re-send, and seat limits on the Starter plan can block onboarding if not monitored.
Removing a member revokes workspace access but does not delete their Observable account, and billing-cycle timing for seat release is not publicly documented - meaning you may need to confirm with Observable support before assuming a seat is freed.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Observable is a practical choice for small-to-mid-size data teams comfortable with a simple role structure. If your team requires automated provisioning, role-based access tied to an identity provider, or audit-grade access controls, Observable's current feature set will require manual process discipline to compensate.
Every app that lacks native SCIM adds operational overhead proportional to your team's churn rate - factor that in before committing to a larger seat count.
Bottom line
Observable's user management is straightforward but entirely manual: invite by email, assign Owner/Editor/Viewer, and remove via the Members tab when offboarding. There is no SCIM, no IdP integration, and no automated inactive-seat detection, so access hygiene depends entirely on admin diligence.
For small teams the overhead is manageable; for larger organizations with frequent role changes, the lack of automation is a meaningful operational gap that should be weighed against the platform's strengths as a notebook environment.
Automate Observable workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
