A developer inherits a model-driven app form script that reads and sets column values through Xrm.Page in an OnLoad handler. The script must be modernized to the supported Client API pattern. What change should be made?
Select an answer to reveal the explanation.
Short Explanation
Xrm.Page is the old master key that Microsoft stopped cutting copies of. You get the right key for the form you're on by asking the execution context for it with getFormContext(), so your code works on the main form, in quick create and anywhere else the form shows up.
Full Explanation
Xrm.Page is deprecated in the Client API. The supported pattern passes the execution context to every form or column event handler, which is enabled by the option to pass the execution context as the first parameter when the handler is registered, and the handler then calls executionContext.getFormContext() to obtain the form context. The form context exposes the data and UI objects for the specific form instance raising the event, which matters when more than one form is present, such as a main form alongside a quick create or a related form. Reaching through parent.Xrm.Page still depends on the deprecated object and adds a fragile assumption about frame structure that unified interface does not guarantee. Caching Xrm.Page in a global variable keeps the deprecated dependency and also risks pointing at the wrong form instance when the context changes. Rebuilding the logic as an iframe that posts messages to the form is a heavy workaround that does not reach the Client API more reliably and adds a separate surface to maintain. Exam caveat: code in ribbon or command scripts receives the form context through the primary control parameter rather than an execution context. Operational check: open the form event handler properties, confirm the pass execution context option is selected, and confirm no remaining script references Xrm.Page.