- 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:
- maintenance cost
- onboarding cost
- operator risk
- hidden business logic
- rollout fragility
When a solution feels hard to explain, move back toward:
- clearer types and properties
- reusable queries
- simpler views
- smaller automations
- documented governance
- 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