Forms, Views, And Canvases Patterns

Pattern

Use the simplest layer that matches the user need.

  1. Start with type and property configuration when the experience is mainly about creating or editing one object.
  2. Move to a view when the work depends on query-backed lists, viewer choice, runtime filters, tags, folders, or view actions.
  3. Add layout-builder tuning inside the view when the screen still fits the view model but needs better arrangement.
  4. Move to a canvas only when the page needs deliberate composition, reusable fragments, widget behavior, or richer scope-driven item logic.

When To Use Standard Form Behavior

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

When To Use Views

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

When To Use Canvases

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

Recommendations

Start With Standard Form And View Behavior

  • 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

Keep Query Logic Out Of The Experience Layer

  • 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

Use Canvases As A Composition Tool, Not A Default

  • 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

Document The Canonical Experience

  • 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

Best Practices

  • 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
Previous← Building A Business AppNextGovernance And Rollout Patterns →