About a year and a half ago, on the eve of Microsoft’s launch of the newest version of Dynamics CRM, I wrote a blog about my first impressions of the product. The blog was based on what I learned at a local Microsoft Partner Launch Event without having really worked with the new version. Now, after working intimately with CRM 2011 for the past 12 months, I wanted to take another look at those first impressions and give an update based upon my recent experience.
With CRM 2011, we were introduced to yet another Microsoft product with the infamous “ribbon” toolbar. By now, we are getting used to it, but let me tell you why the ribbon works so well for CRM 2011. Besides being very visual in its presentation of buttons and options, the ribbon is also fully customizable in CRM 2011. Once you master the syntax and tricks of the ribbon XML, you can do almost anything with the ribbon to make the user-experience easier, as well as, support any integrations and customizations. In our case, we used the ribbon to facilitate a fairly complex integration. We needed buttons in the ribbon to kick off processes and launch windows from a completely separate system. The solution used the context sensitivity of the ribbon to not only determine whether or not to show the button as active or inactive, but also to send key information into the external process to facilitate a seamless user-experience.
Claims-Based Configuration is Tricky
Another big change in CRM 2011 On-Premise is the mechanism for authentication for Internet-facing deployments. Microsoft has switched authentication models from Active Directory to Claims-Based Authentication using AD FS 2.0. This greatly increases the complexity involved with installing and configuring an Internet-facing deployment of CRM 2011. The first step is to install and configure an instance of AD FS 2.0 on the network, which is a task you may want to leave to an experienced network administrator. Once it is configured and running, check out the 41-page document from Microsoft that describes step-by-step how to configure CRM and ADFS to support the secure Internet-facing deployment. Our team required the help of an experienced network administrator to fill in the gaps and missing pieces in order to get authentication working correctly. For most organizations who have an authentication model relying heavily on Active Directory and CRM for its core functionality, it would be considered overkill and unnecessary to use Claims-Based Authentication. We found ourselves wishing that Microsoft had left an option to use Active Directory for authentication in order to eliminate the dependency and risk involved with running and maintaining an instance of AD FS 2.0. Additionally, if your implementation of CRM includes custom .NET screens and services, which require a user to share authentication with CRM, the process and code necessary to make authentication work on both the custom code side and the AD FS 2.0 side is extensive and unpredictable.
The Outlook Client
One of the most publicized improvements Microsoft made with CRM 2011 is a tighter integration with Outlook. The Outlook client integration is by far one of the biggest selling points for Dynamics CRM. The fact that users can leverage email, contacts, and appointments, as well as, their CRM functionality from a single-interface is a huge advantage for Microsoft. With CRM 2011, Microsoft redesigned the Outlook client making the user-experience faster and smoother. However, from our experience, the Outlook client presents one of the biggest challenges, and it all hinges on system performance and user-experience.
Our client’s business hierarchy was flat and its security model was very simple. In other words, most everyone in the company had access to just about all of the data. Initially, we left all of the default views fairly unspecific and trained users to use Quick Find and Advanced Find to search for what they needed. The problem we faced was how Outlook now handles the data, which is presented in its default and “pinned” views for each entity in CRM. In previous versions, the Outlook client behaved just like the web client, requesting data from the server when the user clicked on the particular entity view in the list of CRM folders. The data was then brought down from the server in chunks based on how many rows you configured CRM to show you on each page. This type of “paging” is a standard practice with web applications, which helps reduce server load and improve user-experience with large data sets. However, with 2011, rather than “paging,” the Outlook client actually attempts to download and cache all of that data to your local machine. For example, if you currently have a default view for Accounts that shows all of your Accounts, plus you have “pinned” two other views of Accounts, one showing all Active Accounts and the other showing all Active Accounts with activity in the last 30 days, the Outlook client is going to attempt to download and cache all of that data to your computer, whether you are looking at it or not. It’s not just pulling down the first 50 records, its pulling down the entire dataset. When you couple that with the flat and open nature of our client’s business and security model, we were left with very large sets of data being downloaded from CRM at once across the entire user base. Unlike “synchronization,” which deals primarily with emails and contacts syncing between CRM and Outlook, data caching cannot be turned off.
Since this particular caching functionality and its technical details were not widely disclosed with the release of CRM 2011, our implementation did not take into account key practices to limit the impact to the system. Once the system was live, system monitoring and feedback from end-users quickly showed us that we had a performance issue that had to be addressed. We enlisted the help of Microsoft Support and quickly learned about the new data caching functionality. After that, the solution was fairly straightforward. First, be very specific with the default views for each entity. This represents the bulk of the data, which Outlook will attempt to download. The smaller the dataset, the better the performance will be. Secondly, train the users to limit the number of “pinned” views, especially ones that are “wide open” with regards to search criteria. Thirdly, if your user base is fairly large, use a staged rollout of the Outlook client so that the data is cached by different segments of the business at different times to reduce load on the CRM hardware and software.
Microsoft Dynamics CRM 2011 is a significant improvement over the previous version. Interestingly, the features and functionality, which stood out to me most during that Partner Launch Event are not necessarily the same ones that resonate with me now. CRM 2011 is certainly not flawless, but it represents a great leap forward for the Dynamics CRM product, and we look forward to what the future holds for this product and the value it will bring to our clients.
If you have questions or need assistance determining whether CRM Dynamics is the best option for your organization, please contact Credera’s Microsoft Solutions group.