Permissions

The dedicated Permissions page has working Administration Permissions and Data & View Permissions for ObjectType/field policy configuration.

Administration Permissions

Only Owner mode can configure group grants and individual member grants. In Admin mode, effective permissions combine all active assigned UserTypes' grants with individual additional grants. Removing an individual grant does not override a group grant.

Permission	Controls
people.manage	Members and invitations
roles.manage	Ordinary role assignments and membership removal
user-types.manage	Ordinary UserType definitions
object-types.manage	ObjectTypes, DynamicFields, and schema editing
relationships.manage	Object relationship definitions
queries.manage	Reusable DynamicQuery configuration
settings.manage	Organization name and branding

New admins can enter the Admin Panel but start with no management grants. Owners retain full control in Owner mode. All actions are enforced by the API; hidden controls alone are not authorization.

Data & View Permissions

In Owner mode, select a UserType and ObjectType. Enable Read, Create, Update, or Delete, then choose fields separately for Read, Create, and Update. Save explicitly. Turning off an operation clears its field selections. New fields receive no automatic grants.

Data access follows the selected organization UserType, without combining other assigned roles. Owner mode has full access. Admin receives only its own configured data grants. Choose all records, the member’s own profile, or a bounded relationship path to an explicitly owner-bound profile record; membership expiry/removal and retired definitions block access. Related-only roles cannot create unlinked records; action-only creation requires explicit grants and valid proposed connections. Administration grant aggregation is separate.

Configuring a UserType for data access permanently makes its assignment and retirement Owner-only, including after grants are cleared. This prevents delegated role managers from assigning data-bearing roles. Existing assignments remain; review them before saving new grants.

Record APIs enforce these policies now; see Records and relationship access. Saved query execution and narrowing group restrictions are available. Bounded multi-hop row policies and narrowing group/View restrictions are available. Explicit deny, inheritance, scoped delegation, and approval-required actions remain planned.

Contextual groups and views

Groups now define per-UserType readable/editable bindings and optional assigned-profile eligibility paths. Views can narrow those grants per placement, without changing the shared group. Underlying data permissions remain the ceiling. Optional group context can narrow all-permitted rows to a selected Student; required view context cannot be omitted to broaden that placement.

Relationship editing grants under Data & View Permissions allow declared selectors to replace specific connections. Parent ObjectType Update, a group edit grant, readable query choices and any eligibility condition are also required. This does not grant generic connection administration. See Context, bindings, and views.

For My Details, Only the member’s own profile record restricts the ObjectType to the current account’s explicit profile binding. The selected UserType must use that same profile ObjectType. Create is unavailable in this scope. Optional group/view context can narrow it further but cannot grant another record.

Automatic access through relationships

In Owner mode, choose a UserType and ObjectType under Data & View Permissions. Under Which records?, choose Only records linked through a relationship path and select a continuous path of up to four relationships ending at the UserType's profile ObjectType. Enable only the required operations and fields, then save.

For example, protecting Enrollment with Enrollment → Section → Teacher makes each teacher's enrollment rows follow their bound Teacher profile automatically. A View listing Enrollments needs no Teacher context or manually entered ID. Display Student and Course through explicit group bindings, with the appropriate independent field permissions. The feature works with any organization-defined ObjectTypes.

Open Admin Panel → Records → Member Binding to select a member and bind an existing profile record. Use its Record Connections tab to select a relationship and connect its source/target records. The selectors page through available members and records. Create missing records in the Owner Records manager first. Changes preserve revision checks and relationship cardinality.

Paths use active, tenant-local records and connections. A missing profile or broken path grants no access. Large traversals exceeding 500 connections return an error rather than incomplete results. Profile and connection setup remains Owner-only. A path does not grant access to intermediate fields, expand field permissions or enable standalone record creation.

Action creation permissions

DynamicActions have a separate Owner-managed list of UserTypes allowed to execute. This grant does not bypass data permissions. Enable the action’s record operation and field grants here, and choose Connections allowed during action creation for relationships the action may create. Those connection grants do not grant generic edge administration.

For a related/path-scoped ObjectType, enable Allow Create through authorized actions when proposed connections satisfy this scope, then enable Create and its field grants. Standalone unlinked creation remains blocked. The action must create connections reaching the signed-in member’s bound profile, and all chosen input records and labels must be readable. Own-profile scopes cannot create replacement profile records. Read-only group placements and group field restrictions remain enforced.