Sonoma Partners Microsoft CRM and Salesforce Blog

Turbo Forms: The Time is Nigh

Today's post is written by Mike Dearing, Development Principal at Sonoma Partners.

Released with CRM 2015 Online Update 1, and CRM 2016 on-prem, Turbo Forms was introduced to significantly decrease form load times

And with the recent announcement that the legacy form rendering option will be deprecated, our clients that had yet to take the plunge have begun to express concern.  While it is true that for more heavily customized environments the switch to Turbo Forms can be quite intimidating, hopefully some of the issues that I recently faced will help you on your journey.

Accessing a Form’s Xrm Context From Within an Iframe

Prior to turbo forms, web resources could reliably access their host form's Xrm context by calling parent.Xrm.  However, with Turbo Forms enabled we have found that setting the parent’s Xrm context onto an exposed variable within the resource works well as an alternative.  The parent form can supportedly retrieve the context of the iframe and attach an on load event to it.  The on load event can then be used to reference the parent’s Xrm context, as per the following:

Asynchronous Script Loading

It has always been best practice to ensure that scripts dependent on one another are fully loaded before invoking each other.  The new script engine enforces this as well.  The easiest way to safeguard from falling victim to race conditions is to refrain from calling into separate scripts immediately upon load of a script.  Instead, defer these calls to an on load event handler through the form's properties.  The script engine will load all scripts before calling your load handlers, ensuring that you won’t end up calling a script that hasn’t fully loaded yet.

GetFormType() Returning the Wrong Form Type

One bug that we noticed during our upgrade is that turbo form's implementation of Xrm.Page.ui.getFormType() method doesn't return the proper type for a disabled form, despite showing the correct form type in the footer.  Instead, it will return a form type of 'update'.  This bug is still present as of 2016 SP1/Update 1.  Our workaround for the time being is to do an organization service call to get the access rights of the current user to determine if the form is disabled or not.  This is unfortunately much more inefficient with the overhead of the service call, but is edge case enough that hopefully it won't affect too many implementations. Microsoft support confirmed that a fix will be in place for CRM 2016 Update 2, with a projected release date of 2017 Q2.


Thinking of making the switch soon?  You don’t have to upgrade alone… we’re here to help!

Topics: Microsoft Dynamics CRM Microsoft Dynamics CRM 2015 Microsoft Dynamics CRM 2016