Extending CRM 2011: The Two Towers (actually there are quite a few more…) of Application Event Programming

In my previous post, I discussed the preparation for taking the Extending Microsoft Dynamics CRM 2011 certification exam.  More specifically, how I leveraged the Microsoft Official Curriculum (MOC) to prepare for the information covered in Chapter 5: Plug-ins.  In this post, I will review my preparation for Chapter 6: Application Event Programming.

Continue reading “Extending CRM 2011: The Two Towers (actually there are quite a few more…) of Application Event Programming”

Using CRM 2011 as a Configuration Management Tool

During a CRM implementation it is imperative that not only a great solution is provided to the client, but also to understand how the components within that solution came to be and how they relate to the respective requirements and associated use cases.  This can be done in a number of ways, including the use of Team Foundation Server (TFS), SharePoint lists or other such solutions.  However, if your client does not have the ability or the desire to implement such solutions, you can easily track these changes within the CRM 2011 development environment.

By containing these changes within the CRM instance, your CRM implementation team has the ability to immediately document their changes along with leveraging native capabilities within CRM such as Advanced Find, Views, Export to Excel and SSRS Reporting to support the effort.

How to start?

To get started, create a custom entity within your CRM instance.  You can call it “Configuration Management” for example.  The attributes to include within this entity will obviously vary based on your implementation, however, I have mocked up an example shown in the screenshot below:

Config Mgt
Mockup of a sample "Configuration Management" entity used to track changes within your CRM implementation

TIP: It is important to remember NOT to include this entity or associated entities within the CRM solution which will be exported from the development environment.  This information would not need to be included in other environments as the solutions are promoted.

Best Practices

Attributes to include as a best practice would be items such as:

  • Description of the change
  • Type of change (Add, Change, Delete, etc.)
  • Component Type (Entity, Attribute, Option Set, View, Chart, Jscript, Web Resource, etc.)
  • Detailed description of the function of the component (This also should be the description documented upon creation of the item
  • Related components
  • Unit Testing Information (Who is testing? When? What is the expected result?  Actual? What is the status of the testing?)
  • Traceability details (What requirements are associated?  Use Cases? Business Processes?)


In order to maintain strong traceability between the component and the requirements and/or use cases and business processes, additional entities can be created to document these items and shown on the configuration management entity via SubGrids.  However, if the project is an Enterprise level implementation the cost/benefit may outweigh the time and effort required for this level of data entry if an import is not feasible.

In that event, a memo field to provide the details of the associated requirement numbers, use cases, etc. should suffice.  This information can be extracted from CRM as indicated earlier in the post through an Excel export from a view or through the creation of an SSRS report to support the documentation.

I hope that you have found this post informational.  Have you tried this before?  Please share your experiences by entering a comment below.