Customizing, Extending and All That

Customizing

In Dynamics CRM lingo, the word “customizing” is conventionally used to refer to “schema” customizations: customizations to forms and views, entities and attributes, relationships, and the like. These are “schema” customizations since the changes you make are actual changes to the database schema, and are stored as metadata in the SQL database. These are, for the most part, no-code customizations, and the amazing mileage you can get out of them is a big reason for Dynamics CRM’s exploding popularity as a customization platform.

Extending

While schema customizations have many advantages, they also have some limitations. These can be overcome by more advanced techniques supported by the Dynamics CRM architecture and generally referred to as “extensions”. Specifically, these include:

• Programming with the Dynamics CRM API
• Customizing the CRM UI with SiteMap and ISV.Config
• Developing ASP.NET applications that integrate with Dynamics CRM
• Building and deploying “Plug-ins”
• Building custom workflow activities

These extend Dynamics CRM in a number of ways. First and most important, they let you build extra functionality. For example, if you wanted to build a custom CRM front-end with a richer GUI than the standard CRM web forms offer, you can develop an ASP.NET application that reads and writes to Dynamics CRM via supported web services. Or if you have a requirement that custom business logic execute before a Dynamics CRM record is deleted, that’s something a custom Plug-in can do. Another way in which these techniques extend CRM is that they generally are NOT stored as metadata in the SQL Server database. Plug-ins and custom workflow activities get compiled and their assemblies get deployed onto your CRM server. ASP.NET applications are copied onto your CRM server, by convention to a special folder (”ISV”, for “independent software developer”) underneath IIS (specifically, under “inetpub”).

Extensions are more complex to develop, they require professional development experience and tools (.NET and Visual Studio being by far the most common), and the fact that they’re deployed as external files means you don’t have the convenient all-in-one-place deployment model of a pure schema-customization approach. And by the way, this last point – that they’re deployed as external files – has up to now meant they are also not available for CRM Online, since you can’t just copy your DLLs up to Microsoft’s big IIS in the cloud!

But in return for some increased complexity of development and deployment…you get a lot of cool customization possibilities. These are the main topics I cover in my new Extending Dynamics CRM one-day live online class, and I’ll lay them out in a little more detail in the following table:

Extension Approach	What it’s for, how it works	Examples
API programming	Through compiled code or form script, use a web service such as “CrmService”, which exposes methods such as “Create”, “Delete” and “RetrieveMultiple” (you can probably guess what those methods do!)	Custom dashboards Retrieving and summarizing information for related entities Programmatically changing the schema (adding entities, attributes, etc.)
SiteMap and ISV.Config	Customize two XML files, SiteMap for the left navigation area, ISV.Config to customize the built-in form and grid toolbars, and menus	Customize SiteMap to augment or replace the standard “Resource Center” with your own pages Modify ISV.Config to add custom buttons to the Case or Opportunity forms, which in turn can run code with custom business logic
ASP.NET application development	Build and deploy custom ASP.NET web applications	Create standalone CRM front-end applications for a richer form experience, or as client “portal” applications for external access Create applications to be consumed by an IFRAME on a CRM form, for example custom grids, KPIs and so forth
Plug-ins	Server-based DLLs to implement event-based custom business logic and processing. Complete event pipeline supports both pre- and post-event processing.	Unlike form script, these are not dependent on a form being loaded, so can guarantee code execution regardless of how a record is created, modified or deleted. Unlike the native web UI workflow designer, Plug-ins can fire before a record is deleted or saved, so give you more granular control.
Custom workflow activities	Server-based DLLs to add custom actions to the native web UI workflow designer. Similar to Plug-ins, except designed for use by workflow designers, rather than as event-driven business logic.	These are good for situations when you, as a coder, need to make custom functionality available to people who use the Dynamics CRM workflow designer to build workflows. Do your workflow designers want to calculate aggregate statistics on child records and store them into fields on the parent record? A custom workflow activity can do things like that.

Certification Options

If you’re interested in Dynamics CRM certification, you’ll find a pragmatic distinction between these two concepts expressed in the following two exam prep pages, courtesy of Microsoft Learning:

• CRM 4.0 Customization and Configuration
• CRM 4.0 Extending Microsoft Dynamics CRM