Scopes

Scopes provide multi-tenant data isolation. You model your organization as a hierarchy — for example Tenant → Department → Team — and every request runs in the context of a scope. Records in scope-enabled collections are then automatically filtered so each user only sees the data belonging to the scope(s) they are authorized for.

Scopes work alongside Roles & Policies (a role can be assigned at a specific scope) and Users (a user is granted access to one or more scopes). Navigate to /scopes in the DaaS Studio to manage them.

How scopes work

Scopes are built from three pieces, configured in the three tabs of the Scopes page:

Scope Types — the levels of your hierarchy (e.g. Tenant, Department, Team).
Scope Items — the concrete instances of those levels (e.g. Acme Corp, Sales). Each item gets a canonical URI path such as /acme-corp/sales.
Collection Config — declares which collections enforce scope filtering and how.

When a request comes in, the active scope is identified by its URI path. The server validates that the URI exists and that the user is authorized for it, then filters every scope-enabled collection according to that collection’s configuration.

The active scope is passed on each request via the X-Resource-Uri header (or the daas_resource_uri cookie). A request with no scope is treated as the root scope — see the missing_uri_mode option under Collection Config for how that is handled.

Scope Types

A scope type is one level of the hierarchy. Define types first — scope items reference them.

Field	Description
`Name`	Display name of the level (e.g. `Tenant`).
`Parent Type`	The level above this one. Leave empty to create a top-level (root) type.
`Note`	Optional description.

Create: click Add Type, enter a name, and optionally pick a parent type.
Edit: only the name and note can be changed.
Delete: fails if any scope items still exist under the type.

The parent type cannot be changed after creation — doing so would invalidate the URI paths of every scope item built from it. Plan your hierarchy before creating items.

Scope Items

A scope item is a concrete instance of a scope type — the actual tenant, department, or team. Items form the same tree as their types.

Field	Description
`Name`	Display name of the instance (e.g. `Acme Corp`).
`Scope Type`	Which type this item belongs to.
`Parent Item`	Required when the chosen type has a parent type. The selectable parents are limited to items of the parent type.
`URI Path`	Auto-computed, immutable canonical path (e.g. `/acme-corp/sales`). Not editable.

Worked example. With types Tenant → Department, create the item Acme Corp under Tenant, then create Sales under Department with Acme Corp as its parent item. The Sales item receives the URI path /acme-corp/sales.

Create: click Add Item, pick the scope type, and (when required) the parent item. The URI path is generated automatically. You must create at least one scope type first.
Edit: only the display name can be renamed — the URI path is immutable.
Delete: fails if the item has child items.
The list supports search and is paginated (25 items per page).

Collection Config

Collection configs declare which collections participate in scope filtering and how that filtering behaves. Adding a config wires the collection’s URI field to the scope hierarchy so reads and writes are scoped automatically.

Field	Description
`Collection`	The collection (table) to scope. Immutable after creation.
`Field Name`	The column on that collection holding the scope URI. Defaults to `resource_uri`.
`Missing URI Mode`	What to do when a request has no `X-Resource-Uri` header: `strict` allows null (treats it as the root scope) — `reject` blocks the request.
`Inheritance Mode`	How reads are filtered: `exact` returns only records at exactly the active scope — `down` returns records at the active scope and all descendant scopes.

Create: click Add Config, enter the collection and field name, then choose the missing-URI and inheritance modes.
Edit: the field name and both modes can be changed; the collection name cannot.
Delete: only available for non-system collections.

The system collections daas_user_roles and daas_access come with built-in scope configs (marked system) and cannot be deleted.

Scope-aware access

Scopes integrate with access control. A role can be assigned to a user at a specific scope, and a user inherits the role assignments of their scope’s ancestors — so a role granted at /acme-corp also applies within /acme-corp/sales. The data a user can see in a scope-enabled collection is the intersection of their permissions and the scope(s) they are authorized for.

API endpoints

Scopes are fully manageable over the REST API:


GET    /api/scope/available           — scopes the current user can access
GET    /api/scope/types               — list scope types
POST   /api/scope/types               — create scope type (admin)
GET    /api/scope/items               — list scope items (paginated, searchable)
POST   /api/scope/items               — create scope item (admin)
GET    /api/scope/collection-config   — list collection configs
POST   /api/scope/collection-config   — enable scope filtering on a collection (admin)

Each resource also exposes /:id variants for fetching (GET), updating (PATCH), and deleting (DELETE) a single record. See the API Reference for full endpoint documentation.