Recurring Service Cases

We recently updated our CRM solution for automatically creating recurring service cases. We use recurring service cases to automatically schedule items for our customers that have signed up for managed services or that are under some form of retainer.


I originally implemented this in CRM 1.2 using CRM using special products in our CRM product catalog to represent each service offering. For example we had a product item the corresponded to Server Patch Management and another that corresponded to UPS system check, etc. Each product was related to a maintenance item that was defined in an XML configuration file. The maintenance item contained all the information need to create a service case as well as scheduling information (e.g. 1st and 15th of the month, 2nd Tuesday of the month, 90 days since last completion, etc.)


I created an ASP.NET web service that contained the code to make it all work. When the web service was called it would look through all active CRM Contracts and examine each contract line item to see if the contract line item was for one of our recurring maintenance tasks. If so the code determined if it was time to schedule a new service case and created the case if required. A simple VBScript executed by the Windows scheduler (an often overlooked tool) called the web service daily. It wasn’t elegant but it worked for almost a year and ensured we did not drop the ball on our contractual obligations.


Custom entities in CRM 3.0 have really allowed us to refine this solution. Richard Riddle, one of our CRM developers, took what I had started with and helped me make a much richer and more robust product. We made significant changes in the architecture of the solution by removing all of the complexity of the XML configuration files and placing all of the information on scheduling and product catalog relationships in a new custom entity that we call Maintenance Items. We also implemented the concept of a template service case that makes it much easier to control what information goes into the service cases that are scheduled automatically. Lastly we replaced the ASP.NET web service and Windows schedule with a new Windows Service.


The new system is much easier to configure and gives us greater flexibility. For example we can now have several recurring services associated with one product SKU. This makes it much easier to package our services in the product catalog and makes our CRM Contracts much more readable. So with a little code and a custom entity Microsoft CRM is now capable of scheduling an unlimited number of recurring service cases based on the contracts we negotiate with our customers. 

Gathering Data From Public Web Forms

We have been working on a project that requires harvesting data from a public facing web form. This is a pretty basic request but in the past we’ve only been asked to do this for lead capture and we have generally specified using the C360 web capture tool as a very effective tool for capturing lead data and either relating it to an existing contact or lead or creating a new lead.

However with this project we have to capture data that updates an existing contact or creates a new contact (C360 currently doesn’t support this). We also have to create a custom entity using some of the captured data.

Our first thought was to build a custom web form using ASP.NET and have it connect to the target CRM system using web services. However, we were concerned about three things. First we could not always guarantee that our CRM server would be on line (even the best systems need patching etc.) , the number of hits/second at the public web form could be very high, perhaps higher than the target CRM system could process synchronously and provide a good user experience, and we had no guarantee that the public web server could support ASP.NET.

We decided to make a generic web capture system based on parsing email sent from a web form. Emailing web form data is a basic capability of most hosting platforms so this seemed to clear up compatibility issues. Email would also allow the process to be asynchronous so the users would not perceive a delay. Additionally, email would allow the process to survive a short CRM server outage.

The process is pretty simple. We created a service that monitors a specified CRM email enabled queue. When an email arrives in the queue, the service reads it, parses it, and used the data to create a web request record in CRM (a new custom entity). For auditing purposes we also attach the inbound email the the newly created web request record.

When the web request record is created a workflow rule executes that calls a custom .NET assembly to search for a matching contact record (we use email address just like C360 does) and then either relates the web request to the contact or creates a new contact and relates the web request to the contact. After relating the contact to the web request it is very easy to use the existing workflow functions for dynamic updating to update the contact fields that we want to update. We create and update the custom entity using a similar process.


Minor CRM Gripes

There are not many things that I don’t like about MS CRM 3.0. But one item has recently jumped to the top of the list: Email support for custom entities. I can understand the difficulty in figuring out how to use an email address field in a custom entity to actually create and send an email. What I can’t understand is why I can’t create email templates for custom entities.

I can create email templates for other record types in CRM that don’t represent people (e.g. orders, quotes, service cases.) I should be able to create email templates for my custom entities too. As long as they are related to one of the primary email record types (account, contact, lead) the system should know how to send the email.  Maybe in the next service pack???

By the way coming in at number 2 and 3 on the list are: Can’t call a workflow for one record type from another record type; and Can’t relate a custom entity to a customer (i.e. an account or contact with one lookup.