What this screen does
The Screen Map is a diagram of the application described by your specification: every screen as a node, arrows for navigation flows, and role annotations showing who can reach what. It is generated with the specification and stays attached to it as a version-controlled artifact.
Typical workflow
- Open the Screen Map tab on the Specification page.
- Read it like a floor plan: entry points (login, dashboard) on one side, then follow the arrows a given role would take to complete a task.
- Check each role's reachable screens — a role with access to too much or too little is the cheapest kind of bug to fix at this stage.
- If a screen or flow is missing, refine the boards (Solution shape and Operating model drive this diagram) and regenerate the specification.
- Download the screen map as JSON from the specification's download menu if you want to process it elsewhere.
List types
Select a list screen and open Code generation in the inspector. The List type field decides how the generated app renders that entity's list, in every stack:
- Peek panel (default): the table plus a panel on the right that opens a record in place. Click a row or press Enter; ↑/↓ move through the rows, Esc closes. The panel is fetched, the page address never changes. On phones the row opens the record's page instead.
- Facets and sort: the table with count chips for each status value, a filter on the entity's main relation, and the sort spelled out in words.
- Cards: a card per record with a list-or-cards toggle; the choice is remembered per entity in the browser.
- Plain table: the table alone.
- Data grid and Tree grid: a spreadsheet-like grid (the tree grid nests parent and child rows).
Leave the field unset to get the peek panel. A master-detail console screen offers the same choices for its list. The Filament stack draws these two differently: the grid and tree-grid list types render as a plain table, and the master-detail console becomes that table plus a relation tab per child.
Detail types
A detail screen has a Detail type field in the same place. It decides how the generated app shows one record, in every stack:
- Tabs (default): the record's name and status in the page bar, a strip of its key facts, then the details and each related list under a tab with its count. Previous and next step through the records.
- Header and sections: the record as a document — a header card, then the details and every related list as stacked sections with their counts. Reads top to bottom and prints well.
- Facts rail and related: the record as a workspace — the facts in a rail on the left, the related lists take the width under their tabs. Best for records that are mostly a hub for their children.
Whatever the type, relations link to their records, the status shows in the header, and Delete sits beside Edit.
Form types
A create or edit screen has a Form type field in the same place. It decides how the generated app renders that entity's form, in every stack:
- Page (default): one card with the fields in groups by meaning — who it is for and what it is called, its state, dates and amounts, then the longer text.
- Sections by meaning: the form as a guided document — a card per group, each with a title and one line saying what the group is for.
- Edit with a side rail: the form beside a rail with the record's state, its related counts, the unsaved changes and the danger zone. Applies to edit screens; a create screen of the same entity renders as Sections by meaning.
- Modal: the list's New and Edit open the form in a dialog over the list.
- Drawer over the list: the list's New and Edit open the form in a drawer on the right, fetched in place; the page address never changes.
Modal and Drawer belong to the list, so naming either on a create or an edit screen applies to both New and Edit of that entity. Leave the field unset to get the page.
Regenerating
Regenerate asks the model for a fresh diagram from the specification, and so does generating the map of a new specification version. Your settings come along: the screen type, list, detail and form types, entity and icon of every screen, and the colour, order and icon of every module. They are kept for screens and modules that keep their name, and a renamed screen is still recognised by its entity and type. The note under the diagram says how many screens kept their settings and names any the model no longer produced. Other edits are replaced by the fresh diagram: moved nodes, renamed screens, and added links and notes.
Examples & tips
- The screen map is not just documentation: code generation uses it to build the generated app's navigation and role-based access. A screen missing here will be missing there.
- Right-click a node to ask the project agent about it — for example, "who approves an order on this screen?"
- Orphan screens (no arrows in) usually mean a flow was described but never connected; that is a board-level fix, not a diagram-level one.