Today, I will share with you some tips and tricks when adding custom scripts in your Dynamics 365 application. Here, I shared some of the common scenarios that may require you to write codes. The following scenarios are just examples; you might encounter different requirements, but the same solutions can be applied, so keep an open mind. I thought a one-page reference would be of good help, especially for those who are just exploring Dynamics 365 customization.

Scenario 1: Run a script on form load but ONLY when creating a new record.

Solution: Get the form type of the record and use it as your condition to ensure that you don’t load ALL scripts on every form load.

Syntax: if (formContext.ui.getFormType() === 1)

Value	Form type
0	Undefined
1	Create
2	Update
3	Read Only
4	Disabled
6	Bulk Edit

Scenario 2: Every time you open a form, it says unsaved changes. This is because your form is dirty which means there are fields in your form that have changed. To find out what these fields are, you can use the developers’ tool available in your browser.

Solution: Press F12 while running Dynamics 365. Run the following script in the console and it will tell you the fields that you need to deal with.

Syntax: Xrm.Page.data.entity.getDataXml()

Scenario 3: You are required to set a value in your scripts which is only intended to control logic in the form. This becomes a dirty field.

Solution. Set submit mode to control how you want to save the field you changed programmatically. If you are not interested to store the value, you can choose to do so by setting the submit mode it as “never”.

Syntax: formContext.getAttribute(attributeName).setSubmitMode(mode);

always	The data is always sent with a save.
never	The data is never sent with a save. When this is used, the field(s) in the form for this attribute cannot be edited.
dirty	Default behavior. The data is sent with the save when it has changed.

Scenario 4: You are required to manipulate a lookup field value in the client side.

Syntax: (see image below)

Scenario 5: There are cases when users want to enable auto-save for most forms but disable it for specific forms.

Solution: Get save mode

Syntax: executionContext.getEventArgs().getSaveMode()

Value	Save mode	Entity
1	Save	All
2	Save and Close	All
5	Deactivate	All
6	Reactivate	All
7	Send	Email
15	Disqualify	Lead
16	Qualify	Lead
47	Assign	User or Team owned entities
58	Save as Completed	Activities
59	Save and New	All
70	Auto Save	All

Scenario 6: Hiding and showing UCI tabs. Depending on the users, they can be very particular on working on form tabs.

Syntax: _formContext.ui.tabs.get(tabName).setVisible(false);

Scenario 7: Manipulate UCI tab label and set it as the active tab (focus) on form load.

Syntax: formContext.ui.tabs.get(tabName).setLabel(“Details”); formContext.ui.tabs.get(tabName).setFocus();

Scenario 8: Need to pass a parameter when a certain field value has been changed.

Solution: Add the script file in the form properties and define the JS function in the onchange event of the field. Enable pass execution context as the first parameter.

Syntax: functionName = function (executionContext) { var formContext = executionContext.getFormContext(); }

Scenario 9: You are required to display a notification message on the form.

Solution: Use form level notifications.

Syntax:

_formContext.ui.setFormNotification("INFO", "INFO");
_formContext.ui.setFormNotification("WARNING", "WARNING");
_formContext.ui.setFormNotification("ERROR", "ERROR");

Scenario 10: You are required to display the field values from another entity or table.

Solution: Instead of re-creating those fields in the same entity create a Quick View Form. Another way is to create calculated fields to feed the field value of another entity.

I hope this helps.

For more information on Client API, here is complete documentation for your reference.

If you would like to connect and ask some more tips, feel free to connect with me at LinkedIn.