This recipe shows the typical build path for a tenant implementation that models a real business domain rather than a single isolated list.
- Define the domain with Types.
- Add behavior-rich Properties.
- Create reusable Queries.
- Expose them through Views.
- Organize the solution through Modules.
- Add custom experience only where needed through Canvases.
- Add workflow through Automations.
- Secure and operate the result through Roles And Permissions and Application Settings.
- 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
- 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
- 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
- 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
- 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
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
- 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