Business rules cover a lot of ground, but they top out quickly once logic gets even moderately complex. Client-side JavaScript is the next tool up, running directly in the user’s browser against the form they’re looking at.

What JavaScript can do that business rules can’t

  • Call the Web API to read or validate data from other records in real time (e.g. check a related record’s status before allowing a save).
  • Implement multi-branch conditional logic too complex for a business rule’s simple if/then structure.
  • Dynamically manipulate the ribbon (enabling/disabling buttons based on form state).
  • Control subgrid filtering, lookup filtering, or notifications with custom messages and icons.
  • Integrate with external JavaScript libraries loaded as web resources.

Where it runs — and where it doesn’t

Form scripts only execute in the context of a user actively working in that form in a browser (or the mobile app). They do not run for API calls, data imports, workflows, or plugin-driven changes — anything that bypasses the form bypasses the script entirely. This is the single most important thing to understand before relying on a form script for anything that must always be enforced.

The rule this leads to. If logic represents a genuine data-integrity requirement — something that must be true no matter how the record was changed — it belongs in a plugin (server-side, can’t be bypassed), not a form script. Form scripts are for improving the user’s experience while they’re on the form: convenience, guidance, and dynamic UI behavior, not enforcement.

Where scripts live

Scripts are uploaded as JavaScript web resources (covered in depth later in this course) and registered against specific form events — they don’t run automatically just by existing; each function must be explicitly wired to an event like OnLoad or a specific field’s OnChange.