Here are some of the gotchas you can expect after switching to the new UI that is introduced in December 2012 Service Update, known by the friendly name “Polaris” release. I previously compiled a summary of the changes in the new UI and publish it as the “What’s New in Polaris” slides, but I thought I should highlight a few situations that may come as a surprise when trying to adapt your existing CRM processes onto the updated user experience of Polaris.
Relationship attribute inheritance
As I’ve written earlier, the new forms don’t work all too well with the concept of adding child records from the parent record’s form. Previously in CRM 2011 the ribbon provided a rich, extensible set of actions you could perform on a view of related records or a form subgrid, say contacts related to the parent account or quotes related to the opportunity. While the new Command Bar is about to take the ribbon’s place as the menu of available actions for the main entity form, there’s nothing yet in place to provide similar functionality for related records. Given that CRM by nature is all about managing relationships between different objects, this currently presents quite a severe limitation on the application’s ability to fulfill its purpose.
“Hey, don’t we have those new plus signs on the subgrids that we can use for adding related records?” Unfortunately the answer is not quite as simple, because the actions the button offers are unconfigurable and in most cases suboptimal. Here’s a take from the CRM Online Resource Center article on customizing the forms in the new sales process:
You may add sub-grids to the new process forms as you would with existing entity forms. Note that the behavior of the “+” sign in the new sub-grid will vary, depending upon which controls you have in place on the form. Note that sub-grids cannot be customized to display charts.
- Add Existing and Add New, both. If both are present, the “+” sign control will function as Add Existing.
- Add New only. The “+” sign will open a new record form.
- Add Existing only. The “+” sign will open the classic lookup dialog box.
In most cases we have both options available, which means that instead of the new record form we’re given the Add Existing dialog. Imagine the most basic CRM scenario of them all: adding new contacts for an existing account. Here’s what you get from the form subgrid when clicking the plus sign:
Ok, so it’s not exactly as nice and clean as getting a new contact form right away (the classic experience), but guess we could live with that, since there’s a “New” button available there anyway. However, this reveals one of the hidden but nasty side effects of Polaris: the relationship mappings that you’ve defined in your 1:N Parent Customer relationship between the account and contact entity are not respected when using the New button in the Add Existing dialog. This means that your new contact record will not inherit any values from the account you currently have open, including common fields like address and telephone information. Even the Parent Customer field will be empty, as the system no longer understands the context in which you are adding the new record into the database.
This shortcoming of Polaris renders many common use cases unnecessarily cumbersome. For example, try sending an email from the web UI to a contact record using the new process forms. Although a user who’s completely new to Dynamics CRM might accept the fact that he or she needs to always navigate back to the main window and choose the type of record to create, then fill out all the lookup fields and other non-inherited values, selling this to an existing user of the system would be very tough.
The new process form for the opportunity entity does not show the opportunity products or quotes subgrids/sections by default, you’ll need to enable the visibility in form customization to menu to show them. Once you do, the layout is not very attractive, so you may want to do some clean-up on the form sections. After this exercise you can start to leverage the familiar functionality of adding line items on the opportunity record. No, inline editing of the opportunity products still isn’t possible, but maybe it will one day be in a future release.
As we add more product lines on the opportunity we start to notice that the total amounts are no longer up to date with the latest additions. In the previous UI we would have reached out to the ribbon to click the Recalculate button to force the system to update the record. The new Command Bar doesn’t offer such an option, however. We can’t click the save button either, as there’s nothing to be saved on the actual parent opportunity itself. Our only options to get the totals updated are to A) close and reopen the opportunity form, or B) update any arbitrary field on the opportunity form. In fact, we might as well create a new checkbox field on the form called “switch to update”, to be changed each time we want to perform the calculation. The new auto save feature will then (in no more than 30 seconds) retrieve the updated value, without even flashing the form.
Recalculation is not the only issue here, however. Referring to the relationship attribute inheritance problem that the Polaris UI suffers from, this manifests itself also in the further steps of the sales process. Suppose you’ve added a subgrid for quotes on the opportunity form (or rather made it visible), to allow you to proceed with preparing an offer document to the customer. Clicking on the plus sign works nicely here for a change, since there’s no Add Existing option available for opportunity quotes, so we’re presented with the quote record containing the right header level sums and discounts we entered on the quote. We then click save and… WHAT?!? Where did all my monetary values disappear?! Why is the quote empty now?
The reason this happens is that the quote products were never created. The lack of inheritance doesn’t only limit itself to actions the user performs on the UI, but apparently some of the platform functionality also gets broken when using the Polaris forms. The Add New relationship does carry over the total values from the opportunity form onto the quote form, but none of the line items on the opportunity get added onto the quote. This means that the moment you click save and an update form is opened, the recalculation of the quote level fields takes place, thus deleting the values that existed while we were still on the create form. Sure, you could retrieve the products from the parent opportunity by using the Get Products button on the quote ribbon (as this entity still has the classic experience), but you probably wouldn’t be very happy with this workaround, knowing how it used to work before.
As a part of the Polaris update, the default value of the Revenue field has been changed from “System calculated” to “User provided” in Polaris, as outlined in article KB2806842. I think that sends a clear signal: if you’re working with line items in your sales process, you’d be better off not enabling the new process forms. In which case, don’t forget to go and set the default back to “System calculated” after the update if that’s how you build your opportunities.
A common tip for speeding up the data entry for new accounts & contacts has been to use the lead form to enter all the details on one form, then just convert it to the necessary account, contact and/or opportunity records. Well, now the “or” is gone, as there no longer is a qualify dialog window in Polaris that would present these options to the user when converting a lead. The article KB2808201 says this is by design, so the dialog is unlikely to make a comeback in future versions.
It’s important to note that this doesn’t affect only the Polaris process forms. Also the classic lead form now has two buttons for Qualify and Disqualify, instead of the old one that popped open the dialog window. Once you apply the product updates to your CRM Online organization, you can’t return to the old process. What this means in practice is that users working with the existing “Information” forms that don’t support the concept of creating leads for existing accounts or contacts (like the new one does) may end up creating duplicate records unintentionally.
Sure, the previous experience of having three new windows pop up after the lead conversion was a clear pain point in the system. It was often used to highlight issues with the Dynamics CRM UI logic, so the elimination of separate windows when moving from lead to opportunity must have been a top priority for the product team. However, with the new design you lose the power of choice that had allowed companies to not always create an opportunity record from a qualified lead record. Also, anyone who’s still working with the classic forms no longer even has the option to open up the newly created records, rather he or she needs to go and search them from the main window.
A related minor issue is outlined in KB2808214, which describes how “a script error occurs during lead qualification or leads cannot be qualified in Microsoft Dynamics CRM”. Adding the missing currency field onto the form should fix this one.
The new Tab Control that combines the Activity Feed posts, activities and notes into a single section in the middle of the new forms will render as the notes control once viewing the form in Classic mode. However, there are also changes in how the notes are presented on the traditional “Information” forms. Previously both the Created On/By and Modified On/By fields were visible for notes and attachments, but in the new simplified UI there are only the modification fields left. What this means is that you lose information about who originally added the note and when. I can imagine this having been a useful feature when evaluating the validity of such unstructured information entered on customer records.
Even if you’re not in the habit of editing existing notes once they’ve been entered into the system, there’s a fair chance that the original timestamp and creator information will get lost eventually. You see, a modification is not just someone deliberately editing the text of a note description, it can be some related action such as the assignment of the parent record to a new owner that triggers an update on the notes records as well.
What may come as even a bigger surprise is that you don’t need to be performing any updates to the record at all to accidentally overwrite the Modified On/By fields. Simply clicking on the note and performing a copy & paste will be interpreted as a modification in the new auto save world of Polaris. Although auto save can improve the overall user experience, be sure to vote up this item on MS Connect to help get this issue fixed in a future update.
(Edit 2013-03-29: For further reading, why not check out what the user interface in the upcoming Orion release will be like, to better understand what the end goal of the UI re-design started in Polaris is.)