Views & navigation

An app is a set of views plus the navigation that arranges them. There are two view types — general views (block grids) and form views (data entry) — and one important pattern built from them: the record page.

General views

A general view is a 12-column grid holding up to 24 blocks. Each block is independent, with its own source table and settings — a dashboard mixing a stat row, a chart, and two tables is one general view with five blocks.

Form views

A form view collects a record for one table: you pick the fields, the submit label, and where the app navigates on success. Forms handle both creating new records and editing existing ones. See Forms.

Record pages

A general view that contains a record block is a record page: it renders in the context of one record, opened by a row click from a table, card gallery, kanban board, or any other data view. Every block on the page can use that record — a filtered table of related rows, a comments thread, buttons that run actions on it. Record pages stay hidden from navigation; they exist to be opened from data.

Navigation

• Each navigation item points at a view, with its own label and icon.
• Items can be grouped into collapsible sections — "Sales", "Operations", "Admin".
• Order is exactly what you arrange in the builder.
• A view can be visible to everyone, hidden (reachable only through actions or row clicks), or restricted to specific roles — the sidebar each user sees is filtered to what their role allows.

Ask Ember for a view

The builder's Emberdrawer (View tab) turns a sentence into a view proposal: "a table of overdue inspections grouped by site" becomes a general view on the right table with those fields and a row filter. Nothing is added until you click Add to app; the proposal is a normal draft change after that, so you can tweak it in the editor or revert it like any other save point.

Each ask is a conversation. Keep talking to refine the proposal ("make it a form", "add the due date", "only open ones"), ask Ember questions about the options, and add the view when it is right. Ember replies in context and amends its own proposal rather than starting over. Conversations are kept per app and per tab in your browser, so you can hold several open at once (one per change you are shaping) and switch between them from the drawer's header. A proposal that no longer fits the app (its table or a field was removed meanwhile) says so instead of being added.

The same conversation works in every Ember tab: workflows, PDF and email templates, custom block cards, and sample data. The template tabs keep their picker for reworking an existing template, and the Data tab's proposal is inserted only when you press Insert.