Use the simplest layer that matches the user need.
- Start with type and property configuration when the experience is mainly about creating or editing one object.
- Move to a view when the work depends on query-backed lists, viewer choice, runtime filters, tags, folders, or view actions.
- Add layout-builder tuning inside the view when the screen still fits the view model but needs better arrangement.
- Move to a canvas only when the page needs deliberate composition, reusable fragments, widget behavior, or richer scope-driven item logic.
Use property and type-driven forms when:
- the interaction is field-centric
- the sequence is straightforward
- the runtime context is mostly the current object
- the platform's standard create and edit behavior can express the workflow without page composition
- add-time defaults and forced values from a view are enough to keep the form in the right business context
Use views when:
- users need to compare or act on many records
- filtering, grouping, tagging, or folder context matters
- work is list-centric rather than page-composition-centric
- the same type needs several job-specific screens such as triage, review, planning, or reporting
- the solution should reuse a query as the durable data-selection contract and keep presentation choices at the view layer
Use canvases when:
- one page needs several coordinated parts
- widget reuse matters
- the interaction depends on richer custom layout
- builder-assisted scope needs go beyond normal form or view behavior
- a module needs a custom landing page rather than a straightforward default view
- a property or reusable snippet needs a custom item-tree based interface
- use property configuration, form groups, and form variants before building custom form layouts
- use view creation defaults and forced values when the form needs context from the screen that launched it
- prefer separate role-specific views over one overloaded view when different audiences do different jobs on the same type
- put durable record-selection logic in the query rather than rebuilding it in several views or canvases
- use
relevant_queries for nearby perspectives on the same work surface
- treat tags and folders as runtime operating context, not as substitutes for the core model
- choose a canvas when the page truly needs item-tree composition, nested fragments, widgetized regions, or preload behavior
- use
Snippet and Widget roles intentionally so reusable canvases stay understandable
- keep preload automation, CSS, and scripts small enough that the canvas remains maintainable
- decide which screen is the normal place to create, review, and plan work
- mark specialized canvases and views as specialized in their naming and documentation
- avoid letting several overlapping screens become accidental peers without a clear reason
- start with form and view conventions
- add canvases only for real composition problems
- design each view around one primary job to be done
- use the simplest viewer that matches the job, then tune layout before escalating to a canvas
- treat widget availability and public exposure as access decisions, not presentation tweaks
- document which experiences are canonical and which are specialized