A developer registers a new OnLoad handler, function onLoad(executionContext), on a model-driven form. When the form opens, the script throws because executionContext is undefined on the first line, which calls executionContext.getFormContext(). What is the most likely cause?
Select an answer to reveal the explanation.
Short Explanation
The platform will hand your function the execution context, but only if you tick the box that says to. Forget it and your parameter shows up empty-handed, and that first getFormContext() call blows up.
Full Explanation
Form and column event handlers receive the execution context only when the registration enables the option to pass the execution context as the first parameter. Without it, the platform calls the function with no context argument, unless additional comma-separated parameters were configured, so the parameter is undefined and getFormContext throws. Selecting the option and republishing the form fixes the error without changing the code. The order of libraries in the form's library list does not change which arguments a handler receives; it can matter only when one library depends on another being loaded first. OnLoad handlers do receive the execution context when the option is set, and relying on a global object to read the form, such as the deprecated Xrm.Page, is exactly the pattern the Client API replaced. Async handlers are relevant to OnLoad and OnSave promise support, but returning a promise does not control whether the context argument is passed. Exam caveat: handlers added in code with methods such as addOnChange or addOnLoad always receive the execution context automatically, which is why the problem usually appears with designer registrations. Operational check: open the handler properties in the form designer, confirm the pass execution context option is selected, publish the form, and confirm the handler runs without errors.