Debugging Quick Create Form Parameters

I’ve been working with Microsoft CRM since the release of CRM 2011 (Yes, I know it’s now called Dynamics 365 for Customer Engagement, but just like Jar Jar Binks, let’s just pretend that didn’t happen).  But every now and then it forces me to peel back a few more layers to reveal something new that I’ve never known before.  This is the story of one of those “special” times.

TLDR: When adding form parameters to a quick create form, add them to the default main form as well.  Not doing so will cause your quick create form to throw a server side error and not load.

The Task

I recently received a fairly straight forward task: use the zip/postal code from the parent form (the form from which the quick create is opening from) to populate the tax rate on the quick create.  At least those were the fairly straight forward business requirements.  In order to implement it, I had to trigger a call on load of the Quick Create Form to auto-populate a field based on the results of a CrmWebApi query that used the value of a zip code field on the parent in the query filter.

So the first question was how to get access to the parent form’s attribute.  There are 3 basic options:

1. Setup a field mapping in the entity relationship
2. Pass in the value as a query string parameter
3. Perform a call to the server from the onLoad of the quick create form, to query the data.

Option 1 was codeless, but I didn’t need the zip code field on my quick create entity and I avoid adding data that further denormalizes CRM, so it was at best, a last option.

Option 2 made sense, I just wasn’t sure if CRM supported adding parameters to a quick create form.

Option 3 was doable, but I’d have to make another call to CRM which I also avoid doing.

I quickly opened up the quick create form and saw that it did indeed allow adding parameters, so Option 2 became my saving grace.  I added “DLaB_ZipCode” as a form parameter to the quick create form (who am I kidding?  I totally didn’t read the requirements and attempted just “ZipCode” only to receive a nasty error that an underscore was required), and updated the Xrm.Utility.openQuickCreate call site to include the new “DLaB_ZipCode” parameter".

Finally I updated the onLoad of the quick Create form to get the newly added form parameter, and use it to query the CrmWebApi for the tax rate:

It Works On My Machine

I tested the new functionality by triggering the quick create form, and verifying that I did get the correct tax rate.  Everything worked smoothly, so I pinged my BA and told her it was ready for testing, and went onto my next task.  She ran through a couple quick tests as well and also declared it “programming complete.”  The next day during our daily stand up, a new BA to the project, we’ll refer to him as “Roger”, complained that he couldn’t get that particular quick create form to load.  I quickly ran another test on my machine and it still worked fine.  I asked Roger to test again; still broken for him…  weird. “Hmm… must either be a user issue, or a machine issue… “ I thought to myself.  It also didn’t help that the error was less than helpful: “Error: An Error has Occurred”.  I downloaded the log file but it too lacked anything helpful.  I then asked the original BA to try logging in on Roger’s machine and seeing if she should access the form from there.  A quick log off/log on later, and the results were unchanged.  Roger’s machine was still getting an error.  On a whim, after receiving the error on Roger’s machine, the BA cleared her browser cache, and discovered she was getting the error now as well.  I then opened up an incognito window and found that yes, I was now receiving the error as well.

Spinning A Web

My first assumption was that there was a JavaScript error occurring somewhere.  After diving down a couple rabbit holes, I was unable to find any errors being thrown that I could step into and debug. 

I then decided I must have the parameter name wrong somehow, so while debugging I cleared the parameters array that was being passed into the the openQuickCreate call.  This resulted in the form loading just fine but sans tax rate, obviously.  I closed the form and tried to open it again, this time leaving the zip code in the parameters, and to my dismay it opened just fine, with the correct tax code!  “What sort of magic is this?” I said to myself.  I asked Roger to test it on his machine again, but, even though I managed to fix the problem on my machine, he was still seeing the error.

Ok, so something must be getting cached on my machine that somehow allows the parameter on the form.  I started up a new incognito session and this time, after triggering the quick create from, I typed “localStorage” in the console window and hit enter:

I had never actually done that before and had no idea what I was looking for.  I took note of the 15 items in the storage, and then triggered the openQuickCreate call once more, but this time I removed the zip code parameter.  I once again spit out the localStorage and noted that now there were 18 items in the storage.  Doing a quick visual comparison one of the new keys stood out to me:

LocalStorageCache/EntityDefaultForm/DLaB_Payment: “5F5CC9D7-1E84-4381-AA14-32EA68536233”

Squashing The Bug

Apparently CRM was failing to cache the default entity form.  I then took a wild guess, and added the form parameter to the default main form for the entity and retriggered my test.  No error!  After another request to Roger to test it on his machine, it was confirmed that the bug had been resolved!  I then kicked over the trash can next to my desk in sheer joy and nearly gave my BA a heart attack…  I wouldn’t recommend that.

So What Happened?

Apparently before opening the Quick Create form, CRM attempts to load the default form.  This will cause the default form id to get cached in the localStorage.  Since my BA and I had both already cached this value in my localStorage before adding the “DLaB_ZipCode” form parameter, we didn’t have any issues after it was added.  Since Roger was new to the project, he had never cached the value and since I hadn’t added the “DLaB_ZipCode” parameter to the default form, he was getting the server error.  Adding the form parameter to the default form allowed the initial lookup of the default form to be successful and prevented the error from occurring. 

So if you’re adding form parameters to a quick create form, always remember to add them to the default form as well, even if it “works” on your machine…