Organization Hierarchy

SchemaStack uses a three-tier hierarchy: Organisation → Workspace → View.

Tiers

Organisation

The top-level container. Holds members, billing, and settings.

• Each user can belong to multiple organisations
• Members have an organisation role: Owner, Admin, or Member
• Organisation settings include name, description, website, contact info, VAT, registration number

Workspace

A workspace connects to one external database and contains views.

• Belongs to one organisation
• Members have a workspace role: Admin, Editor, Viewer, or Member
• Stores database connection configuration
• Has an access mode (Active, Schema Locked, Read Only, Design, Maintenance)
• API keys are scoped per workspace

View

A view maps to a table or entity in the workspace's connected database.

• Belongs to one workspace
• Members can have a view role: Admin, Editor, Viewer
• Controls which columns are visible, their order, display names, and widths
• Can be private (explicit access only) or shared
• Has its own column-level permission settings

Role Inheritance

Permissions flow downward with the option to override at each level:

Organisation Owner  →  Full access to everything
Organisation Admin  →  Admin on all workspaces (unless overridden)
Organisation Member →  No inherited workspace access

Workspace Admin     →  Admin on all views in workspace
Workspace Editor    →  Editor on all views
Workspace Viewer    →  Viewer on all views
Workspace Member    →  No inherited view access (explicit ViewMembership only)

View Admin          →  Full design + data access on that view
View Editor         →  Read + write data
View Viewer         →  Read only

A view-level role overrides the inherited workspace role. For example, a Workspace Editor can be given View Admin on a specific view, or restricted to View Viewer.

The Workspace Member role is a special case — it grants workspace membership without any inherited view access. The user can only access views where they have an explicit ViewMembership.

URL Patterns

Admin Console

• /orgs/:orgSlug/workspaces — workspace list
• /:workspaceSlug/workspace/* — workspace detail views

Data Platform (Spread)

• /:orgSlug/:workspaceSlug/:viewSlug — view with data
• /:orgSlug/:workspaceSlug — workspace without view selected

INFO

The URL structure in the Data Platform is simplified — no /orgs/ or /views/ segments. The three slugs are positional.

API Endpoints

Workspaces

• GET /api/workspaces/:orgSlug — list workspaces in org
• POST /api/workspaces/:orgSlug — create workspace
• GET /api/workspaces/:orgSlug/:uuid — get workspace
• PATCH /api/workspaces/:orgSlug/:uuid — update workspace
• DELETE /api/workspaces/:orgSlug/:uuid — delete workspace

Views

• GET /api/views/list/workspace/:orgSlug/:workspaceSlug — list views
• GET /api/views/item/:orgSlug/:workspaceSlug/:viewSlug — get view
• PATCH /api/views/item/:viewUuid — update view
• DELETE /api/views/item/:viewUuid — delete view

Columns

• POST /api/columns — create column
• PATCH /api/columns/item/:columnUuid — update column
• DELETE /api/columns/item/:columnUuid — delete column