Business rules are declarative, no-code logic that runs on a form (or server-side, depending on scope) without writing JavaScript. They’re the first tool to reach for before considering a client script or a plugin.
Scope
- Entity — runs everywhere: every form, and server-side too (including Web API and integration updates). The strictest and safest scope for logic that must always apply.
- All Forms — runs on every form of that table, but only client-side (not on server-side updates).
- A specific form — runs only on that one form.
Choosing “Entity” scope whenever the rule represents a real data-integrity requirement (not just a UI convenience) ensures it can’t be bypassed by an API call or a different form.
What a business rule can do
- Set a field value
- Set a field as required or not required
- Show or hide a field or section
- Lock or unlock a field
- Display an error message or a business recommendation
Rules support simple if/then/else conditions, and can chain multiple actions off a single condition. What they can’t do: loop over related records, call an external API, or implement complex multi-branch logic — that’s where client-side scripting or a plugin takes over.
Why this matters for interviews and real design decisions. A common question is “would you use a business rule or a plugin for X?” The honest answer: business rule for simple, form-visible logic a non-developer could reasonably configure; plugin for anything that must be enforced regardless of how the record was changed (form, API, data import, integration). Business rules with Entity scope sit in between — enforced broadly, but still limited to the simple actions listed above.