Model-Scoped RBAC

What this covers

Model-scoped RBAC lets you grant a user a different access level on a specific model than they have at the project level. This page explains the binding hierarchy, the fallback rules, and when model-scoped bindings are the right tool.

The binding hierarchy

Access in Tessallite is determined by checking bindings in this order:

1. Model-scoped binding — user_access_bindings with model_id set. Takes precedence for operations on that specific model.
2. Project-scoped binding — user_access_bindings with project_id set and model_id null. Used when no model-scoped binding exists.
3. Bootstrap rule — A tenant_admin user can access any model even with no explicit binding.

If none of these match, the request is rejected with 403.

Why model-scoped bindings exist

The typical use case is a project with multiple models where different teams own different models:

• The Data Engineering team needs modeler rights on the raw-data model but should be viewer only on the marketing attribution model.
• An external partner can be granted viewer on one model without having any access to the rest of the project.
• A model under active development can be scoped to modeler-only access while all other models in the project remain available to viewers.

Without model-scoped bindings, you would need a separate project per team — duplicating connections, targets, and shared dimension definitions.

Creating a model-scoped binding

1. Open Tenant Administration → Projects → [your project] → Access.
2. Locate the user row.
3. Click the model-scope icon next to the user's role chip.
4. Select the target model from the dropdown.
5. Select the role to grant on that model.
6. Save.

Or via API:

POST /api/v1/projects/{project_id}/access
{
  "user_id": "<uuid>",
  "role": "modeler",
  "model_id": "<uuid>"
}

Revoking a model-scoped binding

Delete the specific model-scoped binding. The user retains their project-level binding for other models.

DELETE /api/v1/projects/{project_id}/access/{binding_id}

Interaction with row security and personas

Model-scoped bindings control which CRUD operations a user can perform on model metadata. They do not affect which rows the user sees in queries. Row security and persona restrictions apply independently of the binding level.

Roles reference

Related

• Manage Roles
• Configure Row Security
• Project Settings