Chapter 3. Customizing and Designing Applications Within Dynamics CRM 2016 (xRM)
Since the earliest days of Microsoft CRM, the term xRM has been used constantly. The basic idea behind xRM is that the x can stand for anything, and it can be applied to Dynamics CRM as a relationship management tool. Consider this list for a second: cows, vendors, candy, ice cream, money, people, automobiles, semiconductors, airplane seats. Is there anything in this list that couldn’t be managed in an xRM deployment? My answer is always and steadfastly no, and in fact, I’ve seen and built xRM deployments for all of these and many more. If you have been handed a project to build a system for management of something (the x), this chapter is the right place to start!
Note
While I make every effort to consider xRM design concepts and principles, this topic is very large and broad and could fill and entire book. That being said, this book would be lacking without this chapter, which provides the essential basics to give you an understanding of the how and why for xRM.
Tip
Microsoft has moved away from the term xRM in recent years in its marketing materials, instead preferring the term extended CRM.
xRM Explained
In December 2005, Microsoft introduced the third version of Microsoft Dynamics CRM, 3.0 (previous versions were 1.0 and 1.2; 2.0 was skipped altogether). With the introduction of 3.0, Microsoft moved away from the old name Microsoft Business Solutions Customer Relationship Management (aka MBS) to Dynamics CRM. At the same time, it joined the family together with the other Dynamics products—Solomon (SL), Axapta (AX), Great Plains (GP), and Navision (NAV). In addition, the concept of xRM was introduced for the first time.
Explained at the time as the ability to manage anything, xRM provided the building blocks for many organizations to put together applications on top of CRM. One way to think about this is that you use Dynamics CRM as a platform and leverage all the things you need out of it as a sort of “quick start” to get your application done.
Tip
Many organizations have adopted RAD (rapid application design) principles, and Dynamics CRM is an excellent platform for this.
xRM Considerations
When considering an xRM deployment, it is critical to consider the following points:
The end application
The user experience
What comes with Dynamics CRM out of the box
Where you’re going to have to build/extend
The licensing model
The following sections look at each of these in turn.
The End Application
To determine whether Dynamics CRM is a good fit for your situation, you need to consider the end application, or what you’re going to be building. Sometimes it’s a great fit for building out prototypes or proofs of concepts, but the full-scale application might require a different approach. In addition, when you consider application development and a Microsoft environment, you typically consider the following as the base platforms:
Microsoft Dynamics CRM
Microsoft SharePoint
Custom (typically a .NET application built from the ground up)
The first two options, CRM and SharePoint, provide customizers with a platform on which to build their applications. While the last option (.NET) doesn’t, it has much greater flexibility for overall design as there are things that you can’t do using CRM or SharePoint.
Tip
A common way of determining whether an application should be built in CRM or in SharePoint is to consider the following uses:
CRM—Better with structured data, such as appointments and emails
SharePoint—Better with unstructured data, such as pictures and documents
This does not mean that you can’t use either application for what you need, but you need to be aware of the limitations of each. For example, while both have strong workflow engines, CRM does not include native versioning for documents (whereas SharePoint does), and SharePoint does not have the ability to easily cross-reference (that is, relate) dependent objects (whereas CRM does).
The User Experience
How your users interact with your application might determine your platform choice:
Does everybody have strong dependencies on Microsoft Office?
Is the organization standardized on Microsoft Outlook?
Is there a strong demand for a native mobile application?
Does the IT department currently support a large number of Microsoft applications?
Are there any other Dynamics CRM deployments already in place?
If the answers to any of these questions are yes, an xRM deployment will help in designing the deployment and enable users to quickly and easily consume the new application.
What Comes with Dynamics CRM Out of the Box
Leveraging what comes with Dynamics CRM out of the box will help with your planned deployment immeasurably. The best features of Dynamics CRM are often undersold and underutilized, but understanding what they are can help get you to a working application much more quickly than having to design it from scratch.
Some of the highest-value features, discussed in other chapters in this book, include the following:
Native integration with Outlook
Native integration with Microsoft Excel and Word
Strong reporting workflow and reporting engine (SQL Server Reporting Services)
COLAC (explained later in this chapter)
Ability to form dependencies between objects in many relationship types
A user-friendly user interface for configuration
A framework that can be customized easily (with or without code)
For these reasons, organizations continue to use and adopt Dynamics CRM as a base platform both for RAD and for prototyping new applications.
Tip
I often hear that Dynamics CRM comes with too much out of the box. However, you can easily remove all the unneeded objects via two methods:
If you remove (or not grant) permissions to most/all users, the user interface doesn’t display the restricted items, making the application more streamlined.
You can remove objects by customizing the back end of the system and actually removing the unnecessary relationships and objects.
Of these two options, the first is recommended, and Dynamics CRM has been designed with this in mind.
Where You’re Going to Have to Build/Extend
Knowing where you’re going to have to build and extend the application will help with you determine the level of effort before you start. Customizers become more and more comfortable with estimating the level of effort as they get experience working with xRM deployments and learn to understand where the limitations might be.
Note
I’m a huge believer in the notion that Microsoft Dynamics CRM can do anything other than walk your dog, and you’ll see that bias in this book. However, in some cases, the time and money required to make CRM work are too much, and it in those situations, it makes sense to consider alternatives.
For example, there is no core entity for the purpose of cow management, so customizers would have to build this entity to get the development process started. An option to creating an entity for cow management would be to rename an existing entity for this purpose (for example, change the Account entity to the Cow entity). This option works in a lot of cases, but when you use this method, you subject the organization to a potential increase (or step up) in base licensing as you have now used one of the core entities and have disqualified the organization from the lowest and cheapest licensing cost option (that is, Essential).
The Licensing Model
The licensing model of Dynamics CRM provides huge elasticity with regard to what and how an application can be designed. This point can’t be understated.
The section “Licensing Explained,” later in this chapter, provides more information on licensing.
xRM Design Principles
By now you can see that there are some interdependencies when working with Dynamics CRM as an xRM application. When working with xRM, and important question is how to design the application, leveraging the considerations explained earlier in this chapter.
The principles discussed in this section have been tried and true in the real world. That being said, your mileage may vary, and requirements are never exactly the same from one project to another. Sometimes a very small requirement may change the design greatly. The following sections discuss some important considerations: COLAC and licensing.
COLAC
The base entities in Dynamics CRM, which add up to the acronym COLAC, are as follows:
Contacts
Opportunities
Leads
Accounts
Cases
Virtually every standard deployment of Dynamics CRM that is not an xRM deployment uses at least one of these entities. Knowing when and how to use them (as well as the other native entities) is critical in a successful xRM deployment.
Tip
In the 500+ deployments of Dynamics CRM that I’ve personally seen, fewer than a dozen have not had at least one custom entity added to the system. By definition, including a custom entity makes the deployment an xRM deployment.
The dozen deployments that haven’t had custom entities were used strictly for out-of-the-box functions such as lead management or salesforce automation.
Best practices typically dictate one of the following design methods:
Leverage as many out-of-the-box features, functions, and entities as possible and use the fewest possible customizations to make the application meet the requirements.
Build the application around the requirements with an xRM mindset but leverage as much out-of-the-box functionality as possible by renaming and reusing core/native components.
Ignore all out-of-the-box objects and create everything from scratch.
Prior to designing an application and deciding which principle you should follow, it is important to understand how licensing can affect the modeling.
Figure 3.1 shows the effect of using the COLAC, as the entities that are shown (i.e. Opportunity, Lead, and Case) have native integration with Outlook, and there is no way to add new entities to this option in Outlook. As a result, if you wish to extend this type of functionality to Outlook, you need to consider using them.
Licensing Explained
Microsoft has changed the licensing model several times during the life of Dynamics CRM.
In the original iteration of CRM (prior to 3.0), organizations had to pay per module, which means that if an organization wanted to access the Service are or the Marketing area of CRM, it had to pay for it. This was extremely burdensome and difficult for both Microsoft and customers to manage.
The licensing model that Microsoft currently uses is a role-based model that allows users to access certain functions within the system, depending on the license type, or client access license (CAL), they have purchased.
Tip
The concepts related to the license types discussed in this section have been in place for several versions. However, there is no enforcement in the application for any of them. This means you could purchase an Essential CAL and use all the Professional features if you wanted; the system won’t know or care.
That being said, Microsoft has repeatedly indicated that in-app licensing enforcement is coming (it’s actually relatively easy to validate and check with a role report), and there are severe penalties for any organization that is not in compliance with Microsoft licensing.
While the risk to save a few bucks to go with an invalid licensing model might be tempting, most compliance calls to Microsoft licensing are from previous and disgruntled employees, so it’s your call on whether it’s worth it (and you’ll likely have to purchase up once the in-app validation is rolled out).
Figure 3.2 shows the licensing model as it applies to Microsoft Dynamics CRM and any xRM deployment.
Tip
On-Premises licensing varies substantially but still follows the same principles with regard to license type.
As shown, there are three different licensing options available:
Professional
Basic
Essential
Note
In addition, two other licensing options are not shown:
Sales Productivity
Enterprise
These options are not included in this section because they have all the features available under the Professional option and include additional components and applications, such as Parature, Power BI, and so on, depending on the option.
Considering the information shown in Figure 3.2, you can build an application using Microsoft Dynamics CRM, and if you only use custom entities, activities, and notes, you can have a per-user cost of only $15 per user per month.
Note
For more information about pricing and options, see www.microsoft.com/en-us/dynamics/crm-purchase-online.aspx.
A Pure xRM Deployment
A deployment created under the Essential option is considered a pure xRM deployment. A pure xRM deployment leverages almost all custom entities (for example, a custom entity for the purpose of cow management) and doesn’t use anything else in the system. Only a small percentage of deployments can be handled this way, but when they do work, they get all the features mentioned previously—native Outlook, Excel and Word integration, relationship dependencies, and so on.
Caution
Only the most experienced of developers/architects should consider designing an application using the Essential licensing type as it is very easy to neglect some of the dependencies (such as no dashboards or accidently using opportunities or invoices). If you end up using some features you shouldn’t, you will need to step up to a more expensive license or refactor the system completely.
A Hybrid xRM Deployment
The Professional and Basic licensing options yield hybrid xRM deployments. While the Basic CAL meets a lot of requirements, the majority of deployments are a mix of both Professional and Basic licensing. A typical deployment of 100 users might involve 30 Professional and 70 Basic users, but sometimes the numbers can be a lot different, depending on the requirements.
Note
The licensing model shown in Figure 3.2 is subject to change. Be sure to check with Microsoft for any updates prior to estimating actual cost. Microsoft online pricing can be found here: https://www.microsoft.com/en-us/dynamics/purchase-crm-online.
The Effect of Licensing on Design
As the previous sections show, considering licensing when designing an xRM deployment can put severe limitations on the cost of the final application when approved for production. As a result, organizations have to decide if they wish to sacrifice functionality and potentially limit increased usage or desired usage of future functionality for cost today or pay more and having unlimited options. There is no right answer. The best answer is typically a measured approach to design, where the right mix of licenses match with the desired functionality.
The scenario explained earlier—with a 100-user deployment having 30 Professional users and 70 Basic users—is very common, and if the application is architected correctly, the 70 Basic users won’t even be aware of any system limitations. If, however, they someday want to use one of the restricted objects (workflows or opportunities being the most common), they will have to upgrade their CAL.
Note
Microsoft is very aware the organizational needs change, and in fact counts on changes to CALs. If you have an On-Premises deployment and your needs increase, you only have to purchase a step-up CAL to Professional, which is the price difference between the Basic and Professional licenses.
CRM Online customers simply change the pricing selection for the number of users licensed for Professional.
Summary
Considering an xRM deployment of Dynamics CRM is as much art as it is science. The science piece relates to the following:
When, where, and how to use native/OOB functionality versus custom
Whether the considerations for functionality outweigh the implications of cost
The art piece relates to the following:
Which of the half dozen or so different ways the system is designed
Whether the system is as elegant as possible, taking cost and functionality into account
Sometimes the requirements today are not the requirements tomorrow, and prospective owners of an xRM system should consider the future when designing a system, as the hassle of upgrading custom code and entities will cost the customer significantly more than just paying for the additional CALs today.
The take-away from all of this is that there is no right answer, no one size fits all. Yes, you can consider the design requirements, the costs, and the other factors, but if you had the best, clearest, and most detailed requirements in the world, as well as a dozen of the smartest and most experienced CRM designers, you would likely end up with a dozen different final designs. This isn’t a failure but a design feature.