Try Microsoft Edge
A fast and secure browser that's designed for Windows 10
I had an interesting bug in a CRM 2011 CRM solution.
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.
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?
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.
MS CRM 2011 – What is the “IsDirty” Method ?
var attributes = frames.Xrm.Page.data.entity.attributes.get()
var listoffields = "";
for (var i in attributes)
var attribute = attributes[i];
listoffields = listoffields + attribute.getName() + " , ";
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.
This scenario can put the developer in a tricky situation when you have a record in the situation described below
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.
The other factor you need to consider is the potential confusion you are adding to the user when a mysterious save alert.
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?
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?
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.
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.