When interviewing D365 developers and talking to others that dabble in the development side of D365/Power Apps I have come across a fair few people than I thought I would that do not understand a crucial, fundamental thing about JavaScript functionality in D365: it runs on the client side!

It is therefore not in your control, can be manipulated, and should never be used to validate anything important. The request that the server receives can contain any content the user sends, and, if there is no validation on the server to prevent it from being accepted, will be saved to the database.

When a user requests a page on the internet they get a package from the server consisting of HTML, CSS, JavaScript and a few other things like images. Their browser then interprets this and displays the page. While the page is open, more requests may be made from the client for more information or files.

Because my browser gets the files and the data and paints the page, I can do whatever I want with that combination of files, including changing them to function in any way I wish.

For example: if you wanted to make a form read only for some reason or lock a form in a certain status, you might choose to create a file: xyz_onload.js and create a function that checks the status (statuscode) field and locks certain fields or all fields based on the current status of the record.

This will work fine in most instances, but you do need to beware that:

• A user can override this by using something like the LevelUp extension, by writing code in their console, or by editing the file, and
• The functionality you are creating only applies to the form. Any background processes, or even calls to the Web API totally ignore this. Users who have table read/write access in your D365 CRM environment can actually make calls directly to the Web API and ignore the forms and views you have so lovingly crafted.

This concept, and some core lack of understanding about it has actually led to coming up with an interview question which I use with anyone applying to work on our CRMs to screen for this:

“The business complains that users have downloaded the LevelUp extension and are using God Mode to make changes we don’t want them to. Make it so they can’t. What do you do?”

Tiers of answers I’ve heard so far:

• Strong: “Validate any changes with a business rule at the Entity level”
• Weakish: “Block all Chrome extensions”
• Weaker: “Umm you can’t”

A lot of it is due to a number of people not understanding the difference between client side and server side code in D365, and not knowing which functionality runs where.

Within D365, different functionality works on the server side (the D365 instance) or on the client side (the user’s browser):

Server side:

• Business rules set to “Entity”
• Classic workflows
• Plugins
• Power Automate cloud flows
• Logic Apps

Client side:

• Business rules that apply to a specific form
• Business rules set to “All Forms”
• “Read Only” option for fields on forms
• JavaScript on load/on change functions

The best practice (and only real acceptable practice) if that if something actually needs validation for business reasons, it must be done on the server side. Any validation on the client side can be easily worked around and is not something that you should bet the house on.