Permission spaces
Spaces restrict access to entities, attributes, and space-visible app resources. Roles still determine whether a subject can mutate data. A scope such as a locale is a data variant, not a permission space.
Define and deploy
Add space definitions to a project configuration:
spaces: [
{ code: 'catalog', label: 'Catalog team' },
{ code: 'finance', label: 'Finance team' },
],Bind an entity or a global/local attribute with spaces: ['catalog']. This is a fragment of the corresponding configuration object, not a standalone configuration file. Deploy the schema, then open Dashboard → project Members → Manage Access to assign the deployed spaces.
Access rules
| Binding | Effect |
|---|---|
| No spaces on a resource | No additional space restriction; project access still applies. |
| One space | Membership in that space is required. |
| Several spaces | Membership in any listed space is sufficient. |
| Owner | Implicit access to all project spaces. |
Entity restrictions apply to the entity; an attribute restriction does not grant access to an otherwise inaccessible entity. The effective display attribute cannot be space-bound. Relationship-scoped attributes cannot declare spaces.
Verify access
Use a non-owner account with and without the grant. Check Desk visibility and an API request; hidden UI alone is not an authorization test. A Viewer with space membership remains read-only.
API credentials have their own authority. Do not assume a token inherits the issuing person’s spaces. See tokens. Rename space codes as an access migration, not a cosmetic label edit.