A solution validates that a discount column never exceeds 30 percent by using a JavaScript web resource registered on the main form's OnSave event. An integration that creates rows through the Dataverse Web API keeps loading discounts above 30 percent without any error. What change gives the architecture the enforcement it needs?
Select an answer to reveal the explanation.
Short Explanation
Think of form script as a bouncer at the front door: it does nothing about people coming in through the loading dock. Web API calls never load a form, so they never meet your OnSave handler. If a rule has to hold for every path, you put it on the server where every path goes through.
Full Explanation
Form event handlers run only in the client when a user interacts with a model-driven form. Requests sent through the Dataverse Web API, the Organization service, imports or other integrations never load that form, so the script never executes for them. Logic that must apply to every entry point belongs in the server event pipeline: a synchronous plug-in registered on Create and Update in the PreValidation or PreOperation stage can inspect the Target, compare the discount with the limit and throw an InvalidPluginExecutionException, which cancels the operation and returns the message to the caller, whether that caller is a form, a flow or an external service. Adding the script to more forms still leaves every non-UI path uncovered. Business Required is a requirement level that forms enforce; it describes whether a value must be present, not whether a value is valid, and API requests are not blocked by it. A form-scoped business rule is still client-side and runs only on the forms it targets. Exam caveat: client-side logic is for responsiveness and guidance, never the only line of defence for data integrity. Operational check: send a create request with an out-of-range discount through the Web API and confirm the request fails with the plug-in's error message.