Apps & Pages
Apps and pages give your end users a cleaner operational experience than raw configuration screens. They are how you package collections, dashboards, and task-oriented views into department-facing surfaces.
Apps
An app is a lightweight container that groups pages together in navigation. In the current model, apps mainly configure metadata such as name, description, and icon.
Pages
A page belongs to one app and is powered by a single Dynamic UI codeblock: ui_block.
Pages participate in the access-control system, which means:
- users only receive apps and pages they are allowed to access,
- direct form-style bindings remain redaction-aware,
- host-query-driven analytics can still be designed carefully where broader visibility is intended.
What Pages Are Best For
- department dashboards,
- embedded collection browsing,
- task and work-queue views,
- cross-collection summary screens,
- guided operational navigation.
Current page UI blocks are best treated as read-oriented surfaces
Page
ui_blocks currently render in disabled mode. Use them for dashboards, browsing,
and contextual views rather than primary editable submit flows.Worked Example: A Dashboard Page
A strong page usually combines:
- a concise heading and context,
- summary indicators or charts,
- an embedded collection or task surface for deeper exploration.
The Rendering Flow
- The server loads the page definition from the blueprint.
- It executes the page
ui_block. - The codeblock returns a serialized Dynamic UI tree.
- The client renders that tree with the Dynamic UI renderer.
Recommended Page Patterns
- Create one app per department or operational domain.
- Use pages to answer a clear user question, such as "What needs attention today?"
- Embed collection and task surfaces instead of recreating data management from scratch.
- Keep heavy mutation workflows in collection interfaces, where forms are collection-aware.