Remember how extensible previous versions of CRM were? Well, we took that to a whole new level. With CRM 2011 you can define, transport, deploy, maintain and consume full business application built entirely on the CRM framework in days (some core pieces even in hours) and not months. With just a couple of clicks you can declaratively define your data model, processes, user interface and analytics. Advanced extensions such as .Net plug-ins and SRS reports can also be included as part of CRM solutions. All transported and deployed with a uniform model.

Ok, big deal. So CRM 2011 allows me to bundle components and treat team as a “solution”--what is so great about that? That is the key point. It is not just about bundling components but about the fact that the platform now understands the boundaries of a solution and performs intelligent actions accordingly, keep on reading.

Developing and Distributing Solutions while controlling customizations (unmanaged and managed)

The first thing that will strike most newcomers and savvy CRM4 developers is that we introduced the notion of unmanaged and managed solutions. Think of unmanaged solutions as the “source” code of your system and “managed” solutions as the compiled version of your solution. Of course you shouldn’t take this literally because some components in CRM are just “definitions” and don’t require to be compiled; nevertheless the analogy is useful. So, when you initially create a solution it always gets created as unmanaged, you can create new components and perform modifications to others. You can even define some restrictions to ease maintainability of your solution such as setting some components as not customizable.

When the solution is ready for final distribution you export it as managed. When customers install a managed solution we enforce any restrictions that you set (for example prevent customizations on components marked as not customizable). And here is the kicker, while the solution itself cannot be modified, customizable components can still be customized but the system will track those customizations as modification “on top” of the managed solution. So you have the best of both worlds, you can restrict customization of some component while still have built-in extensibility for others without the need to write a single line of code!

Smart updates

But wait a minute, this is a slippery slope. If you allow customers to change your solution (build on top) it will be a nightmare for you to maintain right? Well, not really, we take care of that for you. Whenever you deploy updates to a managed solution the framework automatically preserves customizations performed on top. We have 2 fundamental conflict resolution strategies (merge and preserve) that I’ll explain in subsequent posts but the net result is that customers maintain their customizations while you still deploy your updates.

Automatic Dependency tracking

Gee, but how are you supposed to keep track of what components are used where and not to accidentally delete one that would break another; the problem explodes if you allow customers to further customize your solution. Worry not, because the solutions framework automatically keeps track of all dependencies in the system, isn’t that fantastic?

Build once, deploy everywhere

Solutions built on top of the CRM framework are transportable across all CRM deployment types (Online, Partner Hosted, On-Premises) and all CRM clients (Web, Outlook, Mobile). Truly it is as close as it gets to the holy grail of developers “code once, deploy/use everywhere”. Oh yes, did I mention that we can also take your solutions “Offline” on the outlook client; how many frameworks offer you that kind of functionality?

Solution co-existence

So far so good but what if the user installs multiple solutions from different vendors, aren’t they are going to step into each other toes? No problem, the solution framework automatically handles co-existence of 2 or more solutions when they are installed as managed. The solutions do have to make sense to consume together; while it is technically possible to install two solutions for different verticals (for example Hospital Management and Education Management) into the same organization/tenant the outcome would probably not make a lot of sense for end users, particularly if both solutions want to perform modifications to the same shared component. (For example one wants to turn Account into Hospital while the other one wants to turn Account into School).

Microsoft Dynamics Marketplace

Oh yes, we have a marketplace for you to host your applications that has built-in integration with the product. I’m not going to mention details here because I know for a fact that a lot more information is coming but stay tuned, this is a big deal. 🙂

Solutions Management is a vast topic, I wrote a 20+ pages document explaining the fundamentals, patterns and variations which we are in the process of incorporating into the SDK. While you can get up and going building your first solution in just a couple of minutes mastering more advance topics does take some time, so don’t get baffled, you’ll get there. Trust me, the more your learn the more “ohhhh!” moments you will have; I’ve seen it first hand with some early adopters J

A note about the team behind

Nothing else and nothing more than 40+ people were directly (actually hands-on) on the design and development of the solutions framework and related components. Attempting to name each one would inevitably lead me to miss someone but I do want to show my greatest respect and gratitude to the solutions “platform” team that built the foundation that everything else is built upon. They are (in no particular order): Scott Head, Ajith Gande, Atul Shenoy, Donald La, Christian Betrisey, Brandon Simons, Greg Alicbusan, Jim Daly, Carola Klass, and Elliot Lewis. Special thank you to satellite teams: Application Infrastructure, Visualizations, Reporting and Programmability. You guys rock!