Organization Management & Roles

Roles, Workspaces, and Permissions

Control who in your organization can see and do what, per Workspace.

Until now, everyone in your Sprig account saw every Product and all of its data. If Marketing and People Ops both wanted to run research, there was no wall between their responses. Workspaces are that wall: members belong only to the Workspaces you grant, with a specific role in each, and everything else is invisible to them.

---

What changed, and what did not

Two names changed. Your Products are now called Workspaces, and your Team Admins are now Organization Admins (they also remain admins of each Workspace). Settings are grouped by what they affect: organization-level settings in one place, Workspace-level settings in another.

Nothing changed about anyone’s access on launch day. There is no migration, every member keeps exactly the access they had, and a short in-app note explains the new names the first time you sign in.

How access works

Your Organization contains Workspaces, and each Workspace contains its Development and Production environments. A member holds one role per Workspace: the same person can be an Editor in Marketing and a Viewer in Sales. Members see only the Workspaces they belong to; a Workspace someone does not belong to does not appear in their Workspace switcher, their search, or their links.

A member with a role in a Workspace can access all of that Workspace’s environments.

The roles

Role	In plain terms
Organization Admin	Runs the organization. Automatic access to every Workspace, plus billing, plan, SSO, Domain Access, bot detection, and the org-wide audit log. The only role that can grant admin roles.
Workspace Admin	Runs their Workspace(s): members, settings, SDK and traffic, and the audit log for those Workspaces. Cannot appoint another Workspace Admin.
Editor	Creates, edits, launches, and manages studies in their Workspaces.
Editor Lite	Creates and edits studies but cannot launch, edit live studies, or archive.
Developer	Manages the technical side: SDK and traffic settings, look and feel, replay settings, and integrations. Can launch and edit studies in the Development environment only.
Viewer	Sees studies, results, and dashboards. Cannot create or change anything.

A Workspace can have zero Workspace Admins; Organization Admins administer it directly until one is appointed.

Managing members

Adding. Any member can add people to their Workspace, limited to roles whose permissions all fit within their own (an Editor can add an Editor or a Viewer, never a Developer or an admin). Granting Organization Admin shows a confirmation first, since it means access to everything. One organization setting controls whether members below Organization Admin can invite people who are not yet in your organization; when it is off, new people join only through an admin invitation or an approved request.

Editing. Members are edited one at a time: name, Workspaces, and roles together in one save. The same fit rule applies to edits, checked against both the member’s current role and the new one.

Removing. Only Organization Admins and Workspace Admins can remove members. Removing someone from the organization requires assigning each study they own to a new owner first. If removing a Workspace would leave a member with no Workspaces at all, an Organization Admin sees a warning and may proceed (the member stays in the organization and sees a page where they can request access); a Workspace Admin cannot complete that removal and is directed to an Organization Admin instead.

Protections. Nobody can change their own role or remove themselves. The last Organization Admin can never be removed or demoted; appoint a successor first.

Joining and requesting access

Joining always goes through approval. If someone signs up with an email matching your domain, Organization Admins receive a request and choose the Workspace and role before approving; domain match routes the request, it never grants access by itself. If a member opens a link to a study in a Workspace they do not belong to, they can request access; that Workspace’s Admins and your Organization Admins review it from the Requests tab on the Members page. A denied request sends a neutral email without naming the Workspace.

Emails your team receives

Invitations state exactly what is being granted (every role and Workspace) with one Accept button. Being added to another Workspace as an existing member is a notification, effective immediately, with no acceptance step. Role changes and removals each send one email, and a single admin action that changes several things sends one combined email rather than a pile.

The Audit Log

Every access change is recorded: roles granted and changed, Workspaces added and removed, members removed, Workspaces created or deleted, invitations sent, resent, cancelled, or edited, and Workspace setting changes.

Every entry shows who performed the action (including actions performed by Sprig’s own account team, shown as Sprig account team), when, and what changed. Entries are immutable: they cannot be edited or deleted, by your admins or by Sprig on request, and deleting a Workspace never deletes its history.

Organization Admins see the full organization with user, Workspace, and date filters. Workspace Admins see the same view scoped to their Workspaces. Other roles do not see the audit log. Events are recorded on every plan and become visible on Enterprise, so your history is complete if you upgrade.

Usage

If your account is on the current usage model (MUU, monthly unique users), usage is measured per Workspace: open a Workspace’s Usage page for its numbers, and the organization-level Usage page points you to each Workspace. If your account is on the older model (MTU), you see usage at both the organization and workspace level today, and your account will be migrated to the per-Workspace model.

Keys, tokens, and the SDK

SDK install snippets are per Workspace environment; each Workspace’s SDK & Traffic page carries its own.

API keys are scoped to each Workspace’s environments. Data Import keys come in Development and Production pairs per Workspace, webhook subscriptions are configured per environment, and data export is scoped the same way, so credentials respect the same walls as people. Organization Admins, Workspace Admins, and Developers can view keys; creating, rotating, and revoking them is admin-only, and every key creation, rotation, and revocation is recorded in the audit log.

MCP tokens belong to an individual member and carry only that member’s access: every request is checked against their role in the target Workspace. MCP itself is switched on for the organization by an admin.

A few connections are shared by the whole organization (Sprig MCP, Slack, User Interviews) and are managed by admins; everything else on the Integrations page, from analytics destinations to enrichment sources, belongs to the Workspace where you configure it.

Availability by plan

Capability	Free	Starter	Enterprise
Organization and Workspace model, new names	Yes	Yes	Yes
Organization Admin and Workspace Admin roles	Yes	Yes	Yes
Multiple Workspaces (created with your Sprig account team)	No	No	Yes
Audit log	No	No	Yes
Access requests and approvals	Yes	Yes	Yes

FAQ

Will anything about my access change at launch? No. Names change, access does not. You keep every Workspace and the same role you have today.

Can people outside my Workspace see my studies or responses? No. Members see only the Workspaces they belong to. Organization Admins can access every Workspace, since someone has to administer the organization, and the audit log records what admins grant.

How do I restrict access to one sensitive study? Give it its own Workspace and add only the people who should see it. Study-level permissions inside a Workspace are a planned future capability.

Who can make me an admin? Only an Organization Admin can grant Organization Admin or Workspace Admin. A Workspace Admin cannot appoint another Workspace Admin.

Why does the organization Usage page tell me to check each Workspace? On the current usage model, usage is measured per Workspace, so the numbers live on each Workspace’s Usage page. An organization-level total is planned for a future release.

Can I add a Workspace myself? Workspaces are created, renamed, and deleted with your Sprig account team, and each of those actions is recorded in the audit log. A new Workspace can start with no members at all: Organization Admins administer it until people are added.