A function does nothing until it’s registered against a specific event in the Form Properties dialog (or the modern form designer’s event panel). These are the ones you’ll use constantly.

OnLoad

Fires once when the form finishes loading. The standard place for initial setup: setting default field visibility, applying initial notifications, or pre-populating values based on how the record was opened.

OnChange (per field)

Registered on a specific field, fires whenever that field’s value changes — whether the user typed it, picked it from a lookup, or another script set it programmatically via .setValue(). This is the workhorse event for dynamic, reactive form behavior.

OnSave

Fires when the user attempts to save, and critically, can block the save by calling executionContext.getEventArgs().preventDefault() — the standard way to implement custom client-side validation that a business rule can’t express.

Tab/Section events: TabStateChange

Less commonly used, but available for reacting to a tab being expanded or collapsed — occasionally useful for lazy-loading expensive subgrid data only when its containing tab is actually opened.

Execution order and the “pass execution context” rule. When multiple functions are registered on the same event, they run in the order listed in the form’s event handlers — but only if every function is registered with “Pass execution context as the first parameter” checked. Skipping that checkbox is a classic early mistake that leaves executionContext undefined inside the function, causing a silent (or not-so-silent) runtime error.

Grid events: OnRecordSelect, grid OnLoad

Subgrids and home page grids support their own, separate set of events for reacting to row selection or grid load — distinct from the main form’s events, and registered from the subgrid/grid control’s own properties rather than the form’s event list.