Four chapters covered four separate ideas: why client-side scripting exists, the form context that every script uses, the events a script hooks into, and web resources as the container that gets a script into the system. This chapter walks through one small, realistic scenario that uses all four together, end to end.

Quick facts
  • Scenario: reveal a "Cancellation Reason" field only when Status is Cancelled
  • Four steps: write the script, upload it, publish it, register it against an event
  • Once registered, the browser runs the logic automatically, for every user, every time

The scenario: revealing a reason field on cancellation

Imagine a form with a "Status" field (Active, On Hold, or Cancelled) and a separate "Cancellation Reason" field that should stay hidden most of the time — relevant, and required, only when Status is actually Cancelled.

A Business Rule could almost handle this. But suppose the real requirement is slightly more involved: the reason field should appear immediately as the user changes Status, and a short confirmation message should also be logged to the form. That kind of small extra behavior is what nudges this from "designer-friendly" into "write a few lines of JavaScript."

Step 1 — Write the script

The first step is writing the function itself, using the pattern from earlier chapters: pull the form context out of the execution context, read the changed value with getAttribute, and toggle the other field's visibility with getControl.

Example A function meant to run on the OnChange event of the Status field: 
function onStatusChange(executionContext) {
  var formContext = executionContext.getFormContext();
  var status = formContext.getAttribute("statuscode").getValue();
  var isCancelled = (status === 100000002); // option value for "Cancelled"

  var reasonControl = formContext.getControl("cancellationreason");
  reasonControl.setVisible(isCancelled);

  if (isCancelled) {
    formContext.getAttribute("cancellationreason").setRequiredLevel("required");
  } else {
    formContext.getAttribute("cancellationreason").setRequiredLevel("none");
  }
}
This isn't meant to be a drop-in, runnable file — the real option-set value and field names would come from the actual environment — but it's a fair sketch of the shape a solution like this takes: read the trigger field, decide, then act on the target control through the form context.

Step 2 — Upload it as a web resource

With the function written and saved to a file, it gets uploaded into Dynamics 365 CE as a new JavaScript web resource, given a clear logical name such as new_/scripts/statusform.js — the same upload step covered in the Web Resources chapter.

Step 3 — Publish

The web resource is then published. Until this happens, the uploaded file sits in the system but isn't yet the version users actually load when they open the form. Publishing is what pushes it live.

Step 4 — Register it against the field's OnChange event

Finally, back on the form itself, the new web resource is added as a library the form depends on, and the onStatusChange function inside it is registered against the OnChange event of the Status field — the same registration step from the Web Resources chapter, applied to the specific event described in the Common Form Events chapter.

From that point on, every time a user changes Status on that form, the browser calls this function, reads the new value through the form context, and reveals the Cancellation Reason field exactly when it's needed.

Key takeaway: A form script always follows the same arc: write a function against the form context, upload it as a web resource, publish it, and register it against a specific form event. Once those four pieces are in place, the browser runs your logic automatically, every time that event fires, for every user on that form.

Where to go from here

Client-side scripting has a natural edge: it only runs in the browser, only while a user has the form open, and only with the permissions that user already has. Two situations push logic beyond that edge:

  • Something needs to run on the server regardless of whether anyone has a form open — enforcing a rule no matter which app or integration creates a record. That's a job for server-side code, covered in the existing Plugins & Extensibility tutorial.
  • A script needs to reach out and read or write data beyond the current form — querying related records, or creating something new in Dataverse directly from the browser. That's covered in the Web API & Dataverse tutorial.

Both build naturally on everything in this course.