Writing a JavaScript function is only half the job. Dynamics 365 CE also needs a place to actually store that file, and a way to know it exists at all. That container is called a web resource: a file uploaded into Dynamics 365 CE and given a logical name, which forms and other parts of the app can then reference.
- A web resource is a file — JS, HTML, CSS, an image, and more — stored once under a logical name
- Getting a script live always takes three steps: upload, publish, register
- Publishing is what makes an uploaded file actually take effect for users
- Registering wires a specific function inside the file to a form event
The shared supply closet
Picture a supply closet in an office building: one shared stash of paper, staplers, and pens, stocked once, instead of every department keeping its own. Any room can draw from that same shared supply.
A web resource works the same way inside Dynamics 365 CE: upload a file — say, a JavaScript library your form scripts depend on — exactly once, give it a clear logical name, and any form can be configured to pull from that one shared copy instead of carrying its own private version of the same code.
What kinds of files qualify
A web resource isn't limited to JavaScript. Dynamics 365 CE supports several file types as web resources, each suited to a different purpose:
| Type | Typical use |
|---|---|
| JavaScript (.js) | Form event handlers — the focus of this course |
| HTML | Custom pages embedded in a form via an IFRAME, or opened as a standalone dialog |
| CSS | Custom styling referenced by an HTML web resource |
| Image (PNG, JPG, GIF, ICO, SVG) | Icons, logos, or images shown on a form or in the site map |
| XML, XSL, RESX, and others | Supporting data or resource files for more advanced customizations |
For form scripting specifically, you'll mostly be uploading .js files. But the same mechanism — upload once, reference from anywhere — is exactly how a custom HTML page ends up embedded as an IFRAME on a form too. Both are just different flavors of the same closet.
The basic workflow: upload, publish, register
Getting a script from your editor onto a live form always follows the same three steps, in order:
- Upload the file as a web resource. In the maker experience, you create a new web resource record, choose the JavaScript type, upload your .js file, and give it a logical name following a naming convention such as
new_/scripts/statusform.js. - Publish it. Uploading alone doesn't make the file live — until it's published, the system still has only the previous version (or nothing at all) in front of actual users. Publishing pushes the new file out so it takes effect.
- Register it against a form event. Finally, on the form itself, you add the web resource as a library the form depends on, then attach a specific function inside that file to a particular event — for example, wiring a function named
onStatusChangeto the OnChange event of the Status field, as covered in the previous chapter.
validateCancellation in a file, uploads it as a web resource named new_/scripts/cases.js, publishes the change, then opens the Case form's editor, adds new_/scripts/cases.js as a library, and registers validateCancellation against the OnSave event — at which point every user opening a Case form is running that shared script, pulled from the one closet rather than a private copy.
Skipping any one of these three steps is a common source of "my script isn't running" confusion. A file that's uploaded but not published still behaves like the old version. A file that's published but never registered against a form event simply never gets called at all.