Read the latest from our developers as they share their real world experiences with Form Events.

After waging war against CRM javascript code standards all day and finally seeing the finish line, the OnChange Event I was working on suddenly stopped working.  I delved into the web page as it loaded in browser debuggers and found that the entire file was no longer being loaded, despite being a Form Library and for all appearances being configured correctly.  I cleared out cache, tried different browsers, to no avail.

I’m no stranger to a Solution having issues after importing and reimporting several times in CRM Online… this seems to me to be a bigger problem than older On-Premise installs.  I’ve even seen several cases where an entire online Sandbox instance needed to be reset, through no user fault.  So I started researching online and soon saw people saying that occasionally Microsoft reps will tell folks like us to comment out the “InternalHandler” nodes for issues like this in the customizations.xml file itself (inside the solution zip file).  So, I went ahead and commented some of those out and tried to reimport… then tried again taking out other handlers… tried different combinations of changes, etc.  No dice.

At this point I was starting to sweat, as we were on a tight timeline and starting a case with Microsoft would have been an unacceptable delay.  I kept poking around the customizations.xml file in hopes I would spot something out of place.

So get this: I think CRM actually saved the metadata on the web resource with the wrong file name.  I was at my wit’s end rooting around an exported test solution when I saw this:

      <FileName>/WebResources/new_PhoneCall_Regarding_OnChange_FillFullPhoneNumb6026B2CC-0C2D-E611-80DA-C4346BAD3604</FileName>

Obviously this is useful only at the server side, so they’re adding on their own GUID to the file name.  However, I noticed the last two letters of the word “Number” were missing.  Probably just an intended cutoff to limit file name size, right?  Well apparently no cigar!  I corrected it by adding the “er”, reimported and it all started automagically working again.  Note that this was a separate import attempt with no other changes, so I can’t see what else could have caused this improvement.  If they did intend to limit filename length, they didn’t pen up all their pigs.

Now I have to give the caveat that I haven’t been able to prove this out full circle as it may be a while before we see this problem again; but, if I’m right about the file name being involved, that is definitely a bug, and if I’m wrong, the solution import process is definitely somewhat unreliable.  So either way, something to keep in that back pocket where you keep the Typhoid Mary’s of the CRM troubleshooting world.

 Also another annoying thing I noticed (while working on the above Javascript) is that when using the SDK.REST library from the CRM 2016 SDK, you can’t pass in entity types with the same case as the “entityType” value of a Lookup field.  In other words, if a Lookup is an Account and you ask for the entityType, you get “account”; but, you can’t pass this into a retrieveRecord request.  It has to be “Account”.  So, much as you’d like to clean and optimize your code, in some cases it just won’t get that pretty.  And of course the error was par for the course, as vague as could be.  This feels like someone telling you that you can’t get out of your car using the same door that you used to get in.