The Emergence of Dynamics CRM as the XRM Platform

Summary

The “CRM” in Dynamics CRM stands for customer relationship management, and indeed the 4.0 release is an excellent application for CRM. It comes pre-configured with excellent “out of the box” support for four important functional areas: sales, marketing, service management and service scheduling. It’s a web-based platform based on the .NET 3.0 Framework, sports tight integration with Outlook and the other Microsoft Office applications, and gives customers a choice of an on-premise or a hosted CRM solution.

For a variety of reasons, however, Dynamics CRM is evolving past its CRM-only roots and emerging as a platform for the development of web-based applications in any number of functional areas. These might include obvious extensions of the CRM legacy, but they might be in totally different areas. In recognition of this trend, many have begun to use the term XRM, with the “X” standing for “anything”, driving home the point that it’s no longer just customer relationships we can use the platform to manage.

In this article I will sketch out why I believe this is happening, and why I think it’s useful to think of Dynamics CRM as an XRM platform. If you’re considering creating or upgrading some applications and haven’t had much recent experience with Dynamics CRM, I’ll provide some background on its application development toolset and why you should consider using it. Also, I will include an informal survey of some of the non-CRM functional areas I’ve seen it extended to.

Why Dynamics CRM for Application Development?

Here I will summarize the main reasons for Dynamics CRM’s emergence as a general-purpose application development platform.

1.     It’s the Database, Stupid!

To poorly paraphrase James Carville, the most important reason Dynamics CRM is good for a wide range of business applications its tight integration with and transparent reliance upon the SQL Server database platform. A result of this is that a power-user or a business analyst can use it to create a solid custom database application without writing a single line of code. Web-delivered DBMS applications are important for a wide range of organizations in a wide range of functional areas…and traditionally they’ve been a bear to write! It’s difficult to take an inherently difficult process and turn it into something relatively easy, but that’s what Microsoft’s investment in the Dynamics CRM platform has done.

There’s a bit of jargon to learn, but pretty quickly you get comfortable using the term “entity” for what in another environment you might call a “table” or an “object”; and using the term “attribute” instead of “column” or “property”.

The platform comes with existing entities that collectively define its core CRM functions. For example, “Account” and “Contact” are the so-called customer entities. Opportunity, Quote, Order and Invoice are entities that can be used for an out-of-the-box sales pipeline. The “Case” entity is central to the service management function; “Service Activity” is central to service scheduling, and so forth. Out of the box, Dynamics CRM comes with 54 entities, which can all be customized to varying degrees.

These entities include a well-defined set of “Activities” (phone calls, emails, appointments…) we can use to record our interaction with Accounts, Contacts, and so forth.

You can customize these “out of the box” entities, using the simple, no-code required toolset, in ways like these:

• Customize their forms
• Change their names
• Modify existing attributes (e.g., change display names or picklist values)
• Add custom attributes
• Modify their relationships to each other (e.g., when an account is reassigned do not “cascade down” reassignments to child records)

You can create entirely custom entities with the same toolset. This is where much of the fun begins, since you can design custom entities to accommodate pretty much any functional requirements you can think of. Custom entities are even more “customizable” than the out of the box entities, but since they are still “full-fledged” entities they are just as manageable. You can create and as necessary modify database relationships between your various custom entities and between custom entities and built-in entities. I’ll discuss some examples later in the article.     

2.      Web-Delivered Development Environment

I know that Visual Studio developers scoff at the simplistic “development environment” provided by Dynamics CRM. In fact, with the exception of the workflow design environment, the overall development toolset was virtually unchanged from 3.0 to 4.0. I admit at first I didn’t like the restrictions imposed by this approach: no drag and drop, a single application form for each “entity”, a limited form event model, and so forth. But I got used to it, and I’ve since come to see it as one of the primary strengths of the platform. Here’s why:

• For a wide class of customizations, there is literally no required toolset, since IE is essentially the development environment. This means less configuration and support, and it also lessens the learning investment on the part of the customizers.
• Precisely because the development is limiting, supported customizations all have a similar UI. You don’t get the ransom-note user experience of many of the Access or VB forms out there… because you can’t do that with the supported tools!
• 3. Customizations are Stored in the Database (see #1!)

All of the customizations I’ve described so far are very conveniently stored – as so-called “meta-data” – in the same SQL Server database that stores all of the rows and columns of what we traditionally think of as our application’s data: contacts, accounts, opportunities, projects, etc. This is another of those factors it’s easy not to appreciate the importance of at first. Here are some of the primary advantages:

• Most of your customizations are backed up by and restorable from your normal SQL Server backup/restore routines.
• Customizations are portable in the form of XML files that can be exported from one Dynamics CRM “organization” and imported to another.
• All customizations performed in this “supported” fashion will upgrade from the current version of Dynamics CRM to the next. This importance of this point is easy to miss. What it means is there is a well-defined approach to customizing the platform. At first, it seems a little like nagging, all this insistence on taking a “supported approach to your customizations”! But once you realize it really means that Microsoft tech support is on the hook for making sure your customizations still work when you upgrade to the next version, it pretty much makes the “nagging” worth putting up with.
• The Dynamics CRM platform exposes the UI of all of these customizations through the browser experience. This means that you only need to create a customization once and the platform guarantees its proper functioning wherever and however it’s exposed: CRM on-premise or CRM Online; the web client or the Outlook client.

XRM Examples

This is the easy part, since virtually any application you might tackle with a traditional dbms environment is fair game for Dynamics CRM. I’ll tick off just a few of the more interesting applications I’ve seen, been involved with, or imagined.

• Teacher recruiting and retention: http://www.microsoft.com/dynamics/crm/product/education.mspx
• XRM for government and constituency management: http://www.microsoft.com/australia/dynamics/crm/product/government.mspx
• Event management: http://www.codeplex.com/crmaccelerators/Release/ProjectReleases.aspx?ReleaseId=19077 (this is one of my personal favorites, having been the proprietor of a training firm for the better part of the last 20 or so years)
• Girl’s softball team management. My daughter’s 3^rd & 4^th grade girls’ softball season just ended, and although I didn’t have time (this year!) to work up an application to manage everything, next year I will for sure. Dynamics CRM – XRM, that is – would be ideal for this. I’d create a new organization on my Dynamics CRM 4.0 Enterprise Edition deployment, and customize the Account entity into a “family”. (I normally had one email address per family, and this would give me – finally! – a good reason to send an email to an “account” record.) Contacts would become players, and I’d create a custom entity for “games”. (this would have date & location attributes & so forth, and I’d probably want to track results, even though I know everybody’s really a winner no matter what the score at the end of the game!) I need to think about this a little more, but I’m leaning to a 1:N relationship from “Games” to “At Bats” (another custom entity). Then I need another 1:N, from “Players” to “At Bats”. I think this gives me what I need to keep track of how everybody does, automate the tedious process of sending the emails out to the parents on the schedule…

If you read this far, you might guess I’m as enthusiastic about coaching Bridget’s team as am I about the emerging XRM platform. I think some of the girls actually learned from me why they should tag up on a fly ball with less than 2 outs. Talk about important!

So I’ve got big plans for next year:

• Roll out the softball team management XRM application
• Teach Bridget’s teammates about the infield fly rule

Richard