Anti-Patterns

Avoid

using modules as a substitute for domain modeling
encoding business rules only in canvas layout instead of reusable model or automation structures
duplicating the same query logic across many views instead of naming and reusing a query
using custom queries by default when a configured query would stay clearer and safer
overloading one automation with unrelated responsibilities
using folders or tags as a substitute for core business fields
using a canvas when a standard view or form would solve the problem more cleanly
exposing public links, public modules, or webhooks without governance review
storing secrets in ordinary config fields
relying on undocumented expression tricks instead of clear patterns

Each anti-pattern increases one of these costs:

When a solution feels hard to explain, move back toward:

if navigation feels like the main architecture, go back and clarify the type and property model first
if several screens repeat the same selection logic, create one named query and let views reuse it
if one screen mixes list work, custom composition, and public exposure without a clear reason, split the concerns into a view, a canvas, or a public route with explicit ownership
if tags, folders, or temporary labels are carrying essential business meaning, promote that meaning into the main schema
if an automation is difficult to trace, split trigger handling, delayed follow-up, and integration work into smaller automations with readable variables
if sensitive values are scattered across settings or expressions, move them into the secret store and document their dependencies
if rollout risk is growing, reintroduce version notes, sync preview, and public-surface review as mandatory release steps