Building A Business App

Goal

This recipe shows the typical build path for a tenant implementation that models a real business domain rather than a single isolated list.

  1. Define the domain with Types.
  2. Add behavior-rich Properties.
  3. Create reusable Queries.
  4. Expose them through Views.
  5. Organize the solution through Modules.
  6. Add custom experience only where needed through Canvases.
  7. Add workflow through Automations.
  8. Secure and operate the result through Roles And Permissions and Application Settings.

What To Decide At Each Stage

Types

  • choose stable type boundaries before thinking about navigation labels
  • pick a stable system_name early and avoid renaming it later
  • enable ACL early for types that will carry sensitive or role-dependent data

Properties

  • decide property family, multiplicity, and uniqueness rules before tuning UI details
  • prefer query-backed options when a field should draw from a maintained object set
  • keep calculations, defaults, and show conditions short enough that another implementer can still explain them

Queries

  • name queries by purpose, not only by target type
  • choose the query role based on why the query exists: View, Property, Permission, or User template
  • keep durable business selection in the query and leave user-driven narrowing to runtime parameters

Views And Modules

  • shape each view around one primary job such as review, triage, planning, or reporting
  • use neighboring relevant_queries for adjacent perspectives, not unrelated reports
  • design modules around business journeys and operating areas, not around raw table structure

Canvases

  • add a canvas only when the screen is truly a composition problem
  • use Main, Snippet, Widget, and Property roles intentionally
  • keep preload automation, CSS, and scripts narrow enough that the canvas still reads as a maintained implementation asset

Automations

  • separate immediate event reactions from delayed or recurring follow-up
  • use variables to name intermediate business concepts instead of repeating complex expressions
  • treat webhook-handling and public-entry automation as governance-sensitive behavior, not as an afterthought

Governance And Operations

  • design role priority and permission-query scope before rollout pressure makes the access model harder to change
  • set locale, timezone, onboarding, and delete-behavior defaults deliberately at the tenant level
  • align version publication and tenant synchronization so releases stay reviewable and reproducible

Example Shape

For a service-desk app:

  • types: ticket, customer, SLA, note
  • properties: ownership, due date, status, escalation level
  • queries: open queue, my tickets, overdue, escalated
  • views: triage board, analyst table, manager dashboard
  • modules: support, reporting, administration
  • automations: assignment, reminder, escalation, closure

Best Practices

  • design the model before the navigation
  • keep type and property identifiers stable even when display wording evolves
  • build reusable queries before building many views
  • use Property queries for selectors and Permission queries for access scope so intent stays obvious
  • prefer standard forms and views before introducing canvases
  • add canvases only where standard viewer and form behavior stops being expressive enough
  • keep automations small enough that their trigger, variables, and action graph remain understandable
  • publish versions with readable notes and use sync preview before applying implementation changes
Previous← Automation And Scheduler PatternsNextForms Views And Canvases Patterns →