Skip to content

Runtime screens

The Runtime screens tab configures the three host screens where users work with a record type. Each host screen selects reusable surfaces from the UI surface library and adds its own layout and behavior. Everything defaults to Auto — a generated layout — until a custom configuration is saved.

An Entity List selector may explicitly choose a Parent Tree View, or inherit one from the entity’s default Table Surface. Data Explorer and Details/Drawer related-table hosts preserve that Tree presentation with lazy child paging.

The collection page used by Data Explorer. Configuration covers:

  • which table surface the list renders;
  • list filters — the filters people can add: fields, system fields, statements, and object context facts;
  • actions available from the list.

The desktop Data Explorer grid supports selecting several records for available group actions. Its narrow/mobile card layout intentionally omits selection and the bulk-action bar so each record stays compact and readable; mobile actions operate on one record at a time. Entering the mobile layout clears any desktop selection and pending group action, so returning to desktop starts unselected.

The full record page used when a record is opened:

  • a summary card and an edit form, selected from the surface library;
  • actions — function-backed toolbar actions with label, icon, and placement;
  • navigation and sections — the page layout: cards, sections, tabs, and related-data blocks, including module blocks for Boards and Entitlements.

Entity Instance details do not render a separate signal ribbon. With the Auto layout, Moltaro generates the standard Record data, Comments, Attachments, Assignments, and Stats sections, plus available related-data sections. Runtime capabilities and permissions may hide unavailable sections. Boards and Entitlements are not added automatically; add their hosted sections explicitly. Object Context Facts appear through configured card or table fields rather than through a separate ribbon.

The preview drawer opened from lists and lookup flows. It selects its own summary card and form and has its own navigation and sections, so a quick preview can stay lighter than the full details page. Like the full details page, it does not reserve space for a separate signal ribbon.

Card item widths are responsive to the host’s available space. A shared Card Surface keeps one authored Column span for each item, while Drawer and Details clamp it to the number of columns that fit their own container.

Integrations and agents can fetch the resolved UI configuration through the Entity UI operations: list page, details page, drawer, card, and form payloads.