Concepts

You must be a member of both the org and the workspace to work in product areas.

Workspace vs organization

	Organization	Workspace
Boundary	Policy, SSO, billing, org members	Product data and day-to-day work
Login	No separate login	Selected after platform auth
Typical admin	Org owner / admin	Workspace admin

Workspace roles {#roles}

Role	Typical access
owner	Full workspace control; exactly one per workspace
admin	Manage members, settings, environments
member	Create and edit product data
viewer	Read-only product access

Workspace owner cannot be reassigned with a simple role dropdown. Ownership moves when organization ownership transfers (new org owner becomes workspace owner everywhere).

Org admins can grant workspace access from Workspace → Members or org-level flows when permitted.

Current workspace

The header switcher sets the active workspace for:

Dashboard KPIs
Capture inboxes
Performance runs and scenarios
API calls from the browser (session cookie + workspace context)

CLI and API tokens can pin to one workspace or target via spanline auth workspace use / SPANLINE_WORKSPACE.

Environments {#environments}

An environment is a named set of variables (and secrets) in the workspace:

Referenced by Performance scenarios
Secrets are sealed with the organization public key — plaintext is only available at entry time
One environment may be marked Default

Global Variables and Secrets tabs (separate from environments) are Soon — use environment drawers today.

Dashboard {#dashboard}

The Dashboard is not a separate login — it is the home scene (/) for the current workspace, surfacing:

Quick Capture inbox creation
Recent Performance activity
Shortcuts into active product areas

Multi-workspace accounts

Users in multiple workspaces should:

Pick the correct workspace in the UI before working, or
Set CLI workspace explicitly (see FAQ)

Without an explicit workspace, some API paths fall back to the oldest workspace — risky for CI.