Hi there, thanks for your interest in Orion, the next version of Microsoft Dynamics CRM. You’ve probably arrived here by following a link that promised to show you what the user interface of the upcoming application release was going to be. Unfortunately you won’t find that content here anymore.

Back in March 2013 several Microsoft representatives presented a preview of the upcoming release at the Convergence 2013 event. It was the first time that Orion was publicly shown to MS partners, customers and anyone interested enough in the product to either attend the event in New Orleans or watch the webcasts through Virtual Convergence. I enjoyed the latter ones and took a few screenshots from those sessions (which can still be accessed through the aforementioned site. Based on them, I wrote my own analysis of how the upcoming user interface changes were going to impact Dynamics CRM users, consultants, developers and so on.

It turned out to be quite a popular post. As I write this update on June 28th, the page had been viewed over 11,000 times. Links to the post had been shared almost 300 times on various social channels. Several Dynamics CRM experts contributed to the discussion on the Orion UX changes in the comments section, on LinkedIn and elsewhere. In short, it was a hit.

The reason why the post cannot be available for you to read anymore is that three months after its release my employer has signed an agreement document and the contents of my (personal) blog is seen to be in conflict with the terms of this agreement. I understand the reasoning behind this interpretation and have no problem removing some of the content based on the request I’ve received. After all, I think the post has already done its job in distributing the publicly available information from Convergence 2013 in a structured format that has hopefully made it easier for anyone working within the Microsoft Dynamics CRM ecosystem to understand the direction where the product is heading in its upcoming release.

We’re approaching the moment when Microsoft will be making official information available about the Orion release. At that point there will no longer be a need for any preview screenshots of the UI. If you simply can’t wait for that moment to arrive, then luckily this is the Internet and it does a great job in distributing information to anyone who can be bothered to search for it. If you want to stay on top of the latest news around Microsoft Dynamics CRM, one source of information to keep an eye on is the Surviving CRM Google+ page. If you want to know, how to prepare for Orion, there are some fine articles written on the topic 😉

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.

Opportunity products

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. [Read more…]

In addition to the Surviving CRM blog right here, I have recently also published a few writings on MSDynamicsWorld.com. If you’re not familiar with the site yet, then I recommend you to take a look at their offering and subscribe to their newsletters. In short, MSDynamicsWorld.com is an independent online publication (meaning: not sponsored by Microsoft) that publishes content for Dynamics CRM & ERP users, partners, independent software vendors (ISVs) and consultants.

The articles I intend to write for MSDynamicsWorld.com will be somewhat different than the blog posts you see on Surviving CRM. In my own blog I tend to cover the types of topics that I run into as a part of the day-to-day job of a Microsoft Dynamics CRM consultant: how to do X with Y, workarounds to common issues, updates on the new functionality to be expected from Microsoft & partners, etc. I speak my mind on both the good and the bad, the highs & the lows, in an effort to spread awareness of how anyone working with or around Microsoft Dynamics CRM can make the most of this great platform.

How I’m hoping to leverage this new channel that’s been graciously offered to me by the editors of MSDynamicsWorld.com is to broaden the scope of discussion and look at the world of CRM and Dynamics CRM from a slightly different angle. Instead of the hands-on, application level topics, I’m planning to allow myself some space to move onto a higher level of abstraction and share some thoughts on the business impact and considerations involved with implementing, developing and, at the end of the day, just living with a CRM solution at the customer organization. Don’t worry, it’s not going to be too far detached from the everyday reality. I promise!

My first articles published on MSDynamicsWorld.com are actually series of articles under the theme The Design Language of Your CRM Solution. It’s a journey through the many considerations involved in improving the user adoption rate of CRM systems – a hot topic that never goes out of style, right? I started thinking about these user adoption challenges once again when I heard Bill Patterson make a statement in his WPC 2012 presentation about designing CRM systems that can go viral. Contrasting that with the traditional world of enterprise applications (anti-viral almost by definition) gave me enough food for thought to come up with the following articles:

Part 1: What does it actually require to build a CRM application for viral adoption vs. top-down enforcement?

Part 2: Common sense design principles for making your CRM system easier for the users to adopt

Part 3: The importance of visualizing the processes that the users are expected to follow

Part 4: How the new mobile device clients are helping to make CRM a more lightweight, context-aware application

You’ll need to create a user account at MSDynamicsWorld.com in order to access the full articles. I know, signing up to yet another website can feel like a bit of a burden, but considering it’s an independent publication that doesn’t charge their readers any money, I personally understand the requirement of creating a user account to get access to the content. I’ve signed up for the site already years ago (4.5 to be precise) and haven’t ever come across any messages from them that I would have considered spam emails not relevant to my areas of interest.

Anyway, the choice is of course yours, but I at least encourage you to circle MSDynamicsWorld.com on Google+ or follow their RSS feed, as it’s a great source of news for all things related to the Microsoft Dynamics ecosystem. Oh, and while you’re at it, do make sure that you’re also following the Surviving CRM Google+ stream where I personally share the most interesting blog posts and articles I’ve encountered while surfing the big waves of the #MSDYNCRM community.

Featured Post

Watch out: the Citizen Developers are coming! They are armed with easy to approach GUI tools like Flow, PowerApps and PowerBI, and they aren’t afraid to connect to any of the 160+ cloud apps that you may or may not know your organization is using to solve everyday business problems that the traditional IT projects […]