When to automatically change fields using Javascript
I had an interesting bug in a CRM 2011 CRM solution.
- Open a record
- change no variables and just load the record
- close the record and then a an alert āYour changes have not been savedā are you sure you want to close the record
The user was opening a record, doing nothing but when they went to shut down the record they were asked if they want save their changes
The user is left thinking, I havenāt changed anything. Do I want to save these changes I didnāt make or throw them away? This decision is tricky because you havenāt a clue what has changed.
Why are fields being changed on the on load
I have seen this type of scenario before and it usually occurs because a developer has tried to sneak a calculated field change, e.g. when a contact form is loaded the CRM developer might calculate the full name of a user by concatenating the users names and then updating the fullname field.
The CRM developer has changed a field and made it dirty and only dirty fields are sent to CRM to be saved.
CRM is a place where only dirty entities and fields are saved! The clean fields are ignored. Who invented this crazy world
if you want to understand about dirty fields and what gets saved then read about the SetSubmitMode in this blog post
CRM 2011/2013 ā What does setSubmitMode do? and how does it work?
How to find what field has changed
I had two choices in this scenario, I could either try and find what field is being set by looking at the code or stepping through it.
Unfortunately this was a record with lots of Javascript.
The other choice was to see what CRM attributes have had the SetSubmitMode set to dirty and use the IsDirty Javascript method.
This blog post had the Javascript to do the job
MS CRM 2011 ā What is the āIsDirtyā Method ?
I didnāt want to create a method in the Javascript to call, so instead I brought up the Javascript debugger by pressing F12. Ran this code in the console
var attributes = frames[0].Xrm.Page.data.entity.attributes.get() var listoffields = ""; for (var i in attributes) { var attribute = attributes[i]; if (attribute.getIsDirty()){ listoffields = listoffields + attribute.getName() + " , "; } } listoffields;
The reason I concatenate the fields is once a value is printed in the console it stopped running, so I wanted the output to be after it gave me a list of all the fields which have changed.
It turned out one field was being set. The field was a concatenation of records linked to the record. The related fields were being shown in an html grid and when the user selected a record in the grid, the record was being updated instantly using an odata update. As well as the record being updated there was also some javascript to update a field on the record with a comma separated list of selected records.
To calculate or not to calculate
This is a common problem when CRM developers put calculating javascript code into a form onload. The problem with doing this is the user might not save the record and in which case you will have calculated nothing and potentially confused the user by triggering the save alert.
This scenario can put the developer in a tricky situation when you have a record in the situation described below
- You want to calculate a field for the entity and have this field value saved
- The record does not need to be saved by the user
This problem occurs because the CRM developer is using Javascript on a form on load, so a field value is changed/calculated.
A lot of times you can smuggle you calculated field in amongst user changes to a record so the user doesnāt know the CRM developer has sneakily calculated a field.
If this Javascript is on a record which is often viewed but not changed then I would advise CRM developers not to use Javascript in the onload of the form because the Javascript is not effective because it can keep running and not save the record.
The other factor you need to consider is the potential confusion you are adding to the user when a mysterious save alert.
Would it happen in CRM 2013/CRM 2015
I havenāt tried it but I was wondering if this would happen in CRM 2013/CRM 2015 because they have auto saving.
Auto saving could be turned off, so CRM 2013/CRM 2015 could still work in the same way as CRM 2011.
Itās possible you could try and close the form before the auto save has been triggered, Iām not sure if a save is triggered on closing of a form?
Alternative customization choices
The problem raised is the CRM developer is using an ineffective customization because the record is not automatically being saved. The important question is does this field need to be updated or when does the field need to be updated.
Where and when is the calculated field used e.g how urgent is this field calculation.
If the field value is used in a plugin then a calculation check could be made before the field value is used and this wouldnāt degrade the user experience.
The goal of CRM customizations is to seamlessly work behind the scenes to make the system easier to use/save user time/automate processes. The customization in this scenario isnāt making the user journey easier but puzzling them.
what are the alternatives?
This field calculation should be triggered on the save of a record. In this scenario the record itself is not being saved. In most scenarios I think you could put this code into the OnSave of the record either in Javascript or a plugin.
butā¦
if the record doesnāt need to be saved then I think in this particular scenario you have a couple of choices.
The related record update could trigger a plugin to update the record.
or
An OData update which updates the record on change of the related record which is triggered by an html grid but is then triggering a change to a related entity.
Filed under: CRM 2011, CRM 2013, CRM 2015

*This post is locked for comments