The MS Modern Style Account form
2013 is a big year for CRM Online and CRM 2011 On-Premise. Microsoft has an amped-up roadmap with a ton of great functionality on tap. Some of this has already hit with the December Update for MS Online customers. One of the most notable is the UI refresh, which brings the “MS Modern Style” that is hitting oh-so-many MS apps. The visual update is fantastic as it takes great strides to free users from having so many windows open when using the application. This is fantastic news both on the desktop as well as on mobile devices. Business leadership (and most users) will expect to receive these benefits soon after they’re rolled out.
So, what’s the catch?
Well, I don’t really want to call it a catch, but this certainly introduces some additional considerations as you look forward with your CRM deployment. These considerations could have an impact on the user experience and ultimately impact productivity and usability if not addressed prior to upgrading. There are new wrinkles when it comes to form layout, in-form scripting, and plug-ins. Today, plug-ins are in my crosshairs.
Historically in MSCRM, users would have to click a Save button when they’ve worked with a record (Save, Save and Close, etc.). The MS Modern Style form brings the web 2.0 concept of automatically saving a record that is being edited. From a user’s perspective, that’s mostly good (though an undo button would be nice). The specific mechanism triggering this save is a timer, which saves saves changes to the CRM database every 30 or so seconds if there have been changes.
Right there, that’s a little interesting. It’s time-based, not event based. Sure there’s still a Save button you can click, but if I take 90 seconds to update a record, 2-3 saves will have taken place during that time. So, let’s consider a plug-in that fires when a record is updated. In the soon-to-be-old-world, it would have executed one time (when I clicked save). In the soon-to-be-new-world, it will have executed 2-3 times (or maybe even 4 if I ended up clicking the save button manually when I was done).
This can get you thinking of a handful of questions about existing plug-in design…
- Are your plug-ins resource intensive? What if they’re running at 2x the frequency as today (or 3x…4x)?
- Do any of your plug-ins trigger a chain of events?
- Do any of your plug-ins rely on the fact that today they only execute when you’re finished working with the record?
- Do any of your plug-ins rely on something that’s been done to the record via client-side scripting?
- Do any of your plug-ins do a validation that requires certain groups of fields to all be updated (think address city/state/zip code validation)?
So what do the answers to these questions mean? They give a picture to how much of an impact some of the 2013 updates may have on your users. Generally speaking, these aren’t likely to stop the business in its tracks. That said, it would be unfortunate to introduce performance and user experience issues that cloud the positive impact of the fantastic new functionality users are getting this year.
In a quiet nod to this, the CRM Team Blog recently posted a couple of items. One detailing the specifics of the save behavior (along with a note that it can impact the items called out above), another about plug-in design. The posts are quite technical, so if you’re not feeling geeky today you can instead read the following commentary:
The CRM SDK describes plug-ins as “custom business logic (code) that you can integrate with [Dynamics CRM] to modify or augment the standard behavior of the platform”. This means plug-ins are beyond the platform that MS is responsible for (Read: it’s your problem if it’s not working right). MS felt like it’s important to post information about plug-in design in parallel with the news about product updates. Change is a-coming, and it may not play nice with your existing customizations.
Talk with your CRM Administrator about the plug-ins you’re using and assess the type of impact these updates will have. Most of these issues can be addressed…but remember: plug-ins are written in .NET, which means you’ll need a developer, which means you’ll need regression testing, which ultimately means you’ll need cycles from multiple teams of people.
Now is the time to get the conversation going.