Appearance
Context, bindings, and reusable groups
A DynamicGroup is a reusable table or form. It does not require a query. Choose its row ObjectType, displayed fields, optional queries, and per-UserType access.
All records or one record
For a reusable Student group:
- Choose Student as the row ObjectType.
- Add a
studentinput context of type Student and leave Required unchecked. - Choose that context under Narrow rows when this context is supplied.
- Leave the relationship path empty: the supplied context is the Student row itself.
Opened alone without a Student ID, the group shows all Students the selected role may access. Supply Student A's ID and it shows only Student A. Invalid or inaccessible IDs are rejected; they never cause a fallback to all rows.
For Grade rows filtered by Student, choose Grade as the row ObjectType and explicitly select the Student → Grade relationship as the context filter. All record and field permissions still apply.
Display fields from several records
Each displayed binding names its source: the current row or an input context, an explicit relationship path, and a record field. For example, a Grade row can display:
| Display | Source | Editing |
|---|---|---|
| Student Name | Supplied Student.name | Read-only |
| Course Name | Grade → Course.name | Read-only |
| Assigned Teacher | Grade → Teacher.name | Live relationship selector |
| Grade | Grade.value | Update the Grade record |
Display paths must identify one record and have at most two relationship steps. Never infer links from matching names.
Choose Edit this record field for a normal field write. Choose Choose a related record from a live query to replace a connection. The latter requires a saved query that returns the destination records and projects the label field. The selector's choices are live; the server rechecks eligibility when saved. Selecting a Teacher changes the connection, not the Teacher's name.
Permissions
Configure read/edit bindings per UserType. For a Student My Details page, set the underlying Student data scope to Only the member’s own profile record and bind the account to its Student profile. The same unfiltered group will then return only that Student; guessing another Student ID does not expand access. Editing remains bounded by underlying data permissions. A role allowed to view a Student does not automatically gain access to financial records. Relationship selectors also require explicit Relationship editing grants under Data & View Permissions, parent ObjectType Update, and a group edit grant.
For “only the assigned Teacher can edit Grade,” add an eligibility path from the Grade row to the UserType's owner-bound Teacher profile. Underlying row policies should hide unrelated Grade records where appropriate. Switching roles changes effective access.
DynamicViews
Open Views → Configure views in Owner mode. Declare any required input contexts, add reusable group placements, and map group inputs to view inputs.
A Student Details view requires a Student ID and maps it to the Student group's optional student context. An All Students view can have no required contexts and reuse the same group without supplying that context. View placement restrictions may hide fields, narrow editing or visibility, or make the placement read-only; they cannot expand the group's data access.
Open Views to use a page. Declared view contexts must be supplied before data loads. Standalone group access remains governed by its own permissions; view filters do not replace global record-access rules.
Existing groups
Existing query-backed groups continue working. Owner configuration offers Use field bindings for an explicit conversion. Compatibility migration preserves their IDs, permissions, versions and history. New contextual displays support reads and explicit per-field updates. Existing record APIs and query-backed group CRUD remain available for creation/deletion; contextual multi-record creation and record picker/search are later work.
Records and summaries update
Owner Records, contextual anchor-record creation/deletion and permission-aware summary groups are implemented. See Records and summary groups. Authorized record search and prompted action record pickers are available. Multi-record creation remains planned.
The group designer places Name, Key and Display in three columns, with compact row-source columns below. Input contexts and displayed-field/write bindings use editable tables. Per-UserType access offers Tabs and List layouts; switching layouts preserves unsaved grants. Tables keep every configured row visible while editing.
Field rows show schema type, required status and default, with an ObjectType configuration link. Required in this group adds a validation requirement for field creation/edits through this group; it cannot relax schema validation. Role panels identify missing required schema fields during creation; the runtime also checks data policy and view restrictions. Unavailable Add actions show an explanation. Field types remain immutable after creation; changing a type requires a new field and data migration.
Definition administration
Admin Panel → Views & Groups opens /org/{orgId}/views-and-groups, with Groups and Views tabs containing definition tables. Add opens /{groups|views}/new/manage; Configure opens /{groups|views}/{definitionId}/manage. Save retains the current definition and version. Back returns to the corresponding catalog tab. Configuration remains Owner-only. Standalone Groups and Views pages continue to display permitted data. Previous /groups/manage and /views/manage links redirect to the catalog. Legacy query groups retain their editor and explicit field-binding upgrade.
Personal favorites and dashboard pins
Select a star on a Group or View card to save it to your personal Favorites tab. Select the pin to place its quick-access card on your organization dashboard. Stars and pins are independent, persist across sessions and devices, and belong to each user within each organization (not to the selected role). The administrative Groups/Views tables also offer these controls. Role changes or retired definitions hide inaccessible saved sources; favorites never grant access. Groups and Views requiring context still request it after opening. Each list supports up to 200 saved sources.
Icons
Group and View configuration offers an optional icon picker with preview. Cards, favorites and dashboard pins show the saved icon beside the name. A view placement defaults to Inherit group icon, which follows later group-icon changes. Select a different icon to override it for that placement, or No icon to hide it there. Definition icons use the shared available-icon list; existing definitions without icons continue to work. API icon accepts a listed identifier or null/empty for none; placement icon: null (or omitted) inherits, while an empty string hides it.
Views as the member entry point
Views are the user-facing pages. Regular users access reusable Groups only through authorized View placements. The Groups navigation, standalone previews, Group favorites and Group dashboard pins are Owner-only. A one-table page is a View containing one Group. Member requests to contextual Group metadata, rows, lookups and mutations must include a valid viewId, placementKey and viewVersion; existing context mapping and per-placement restrictions remain enforced. Direct member Group listings return an empty list, and direct operations fail with VIEW_REQUIRED. Legacy query-only Groups remain Owner previews until explicitly upgraded to field bindings and composed into Views. Existing member Group preferences remain stored but hidden; View favorites and pins continue working.
Icon configuration now uses a searchable visual grid with a glyph and name for every choice. Placement choices still support inheritance, overrides and no icon.
The icon picker defaults to the curated selection. Turn on Show all Bootstrap icons beside the picker heading to search the complete installed library. Show more icons extends the result grid in batches. Switching the toggle does not clear the selected icon, and icons from the full library work for Groups, Views and placement overrides. npm run icons:sync generates frontend/source-icons-all.json from the installed package; production builds refresh it automatically.
View page appearance and descriptions
Open an authorized View page and choose Modify View, or a Group page and choose Modify Group. Owner mode currently holds definition-management access; record edit permission alone does not expose these actions. Owners can also modify a Group directly from its section within a View. Saved definition editors offer Open View / Open Group to review the page.
Both Group and View configuration include a plain-text Summary / description. Descriptions appear on their pages and listing cards. View configuration additionally includes Page appearance: background color, table-section border color, compact/comfortable spacing, Show Back to Views button, Show page title, and Show favorite star next to the page name. Colors are constrained to color values rather than custom CSS. The star uses each member's existing personal View favorites; hiding it does not remove saved favorites or alter access.
Every View placement may have a Section title (optional). This is useful when the same reusable Group appears more than once. Multiple groups have jump links and independent outlined sections containing their headings, descriptions, navigation actions, table controls and record paging. Record search and enabled column filters run across authorized rows before pagination. A separate Filter this page control, where offered, filters only loaded rows. Previous/Next fetch other permitted record pages. Schema validation, per-cell permissions and View restrictions apply to every write. Group tables use explicit Save/Cancel; Sheets autosave individual cells.