> ## Documentation Index
> Fetch the complete documentation index at: https://docs.siftd.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Workspaces

Workspaces are the core organizational unit in SPIN, grouping notebooks, connections, runtimes, and users with shared access controls. Think of a workspace as a project or team boundary containing all resources for a specific set of activities.

## Workspace Concepts

### Purpose and Scope

Workspaces let you:

* **Organize Resources**: Group related notebooks, connections, and runtimes
* **Control Access**: Manage who can view, edit, or execute notebooks
* **Share Context**: Provide a common environment for collaboration
* **Audit Activity**: Track all operations within a defined boundary

### Workspace Hierarchy

SPIN supports parent-child workspace relationships:

* **Parent Workspaces**: Manage connections and runtimes that can be inherited
* **Child Workspaces**: Inherit connections and runtimes from their parent
* **Benefits**: Centralized credential management, distributed notebook access

## Creating and Managing Workspaces

### Creating a Workspace

Any organization member can create a workspace:

1. Go to your organization dashboard
2. Click **Create Workspace**
3. Enter a descriptive name and optional description
4. Optionally select a parent workspace (if permitted)
5. Configure initial settings

### Workspace Settings

Configure workspace behavior and policies:

* **Name and Description**: For clear identification
* **Parent Workspace**: Inherit connections and runtimes
* **Default Runtime**: Set a preferred runtime for new sessions
* **Session Retention**: Configure how long execution logs are kept

### Workspace Deletion

* Only organization admins can delete workspaces
* Deletion preserves session logs for audit compliance
* Consider archiving inactive workspaces instead of deleting

## Role-Based Access Control

SPIN implements a comprehensive RBAC model for workspace access:

### Workspace Roles

| Role       | Description                                     | Typical Use Case                |
| ---------- | ----------------------------------------------- | ------------------------------- |
| **Owner**  | Full workspace control                          | Team lead, project manager      |
| **Editor** | Create/edit notebooks and invite agents/viewers | Senior engineers, SREs          |
| **Agent**  | Execute notebooks but cannot modify them        | Junior engineers, support staff |
| **Viewer** | Read-only access to notebooks and results       | Stakeholders, auditors          |

### Permission Matrix

| Action                    | Owner | Editor    | Agent | Viewer |
| ------------------------- | ----- | --------- | ----- | ------ |
| View notebooks            | ✅     | ✅         | ✅     | ✅      |
| Create/edit notebooks     | ✅     | ✅         | ❌     | ❌      |
| Execute notebooks         | ✅     | ✅         | ✅     | ❌      |
| Manage connections        | ✅     | ✅         | ❌     | ❌      |
| View connection details   | ✅     | ✅         | ❌     | ❌      |
| Manage runtimes           | ✅     | ✅         | ❌     | ❌      |
| Invite users              | ✅     | Partial\* | ❌     | ❌      |
| Modify workspace settings | ✅     | ❌         | ❌     | ❌      |

\*Editors can invite agents and viewers, but not other editors or owners

### Organization-Level Roles

* **Organization Admin**: Full access to all workspaces and settings
* **Organization Member**: Can create workspaces and be invited to others

## User Management

### Inviting Users

To add team members:

1. Go to **Workspace Settings** → **Members**
2. Click **Invite User**
3. Enter the user's email address
4. Select the appropriate role
5. Send the invitation

Users must be organization members before they can be invited to workspaces.

### Managing User Roles

Workspace owners and organization admins can:

* View all workspace members and their roles
* Change user roles (with permission restrictions)
* Remove users from the workspace
* Transfer workspace ownership

### Role Transition Guidelines

When changing user roles, consider:

* **Promoting to Editor**: Ensure the user understands connection security implications
* **Demoting to Agent**: User loses ability to modify notebooks but retains execution access
* **Moving to Viewer**: Useful for stakeholders who need visibility without operational access