Now You Can Handle “Nearly Static” Data with Microsoft Dynamics CRM 2011

Visit Website View Our Posts


** CRM 2011 Developer Content Ahead! **

** The post includes content that may be hazardous to users not interested in JavaScript or XML files **

Microsoft Dynamics CRM has always been an excellent tool for handling dynamic data and its associated relationships. The system does a great job of dealing with the rapidly changing, ever in motion data associated with fast-paced business. What has been missing is a way to deal with “nearly static” data - that is until Microsoft Dynamics CRM 2011.

Let’s take a theoretical system where you want to automatically populate the City and State fields based on the user entering the five digit zip code. The zip codes and their association with a city and state are nearly static, and don’t change very often. Adding the functionality would greatly improve data entry quality and increase address accuracy, not to mention data entry speed. There are just over 42,000 zip codes that would need to be handled and stored somewhere for easy retrieval.

To provide this functionality we will need to add a JavaScript “OnChange” event to the zip code field and lookup the city and state based on the user’s entry. The challenge is storing the 42,000+ zip codes and accessing them on demand without adding excessive overhead to the system or violating any of the CRM deployment guidelines. It is in the storage and retrieval of this data that CRM 2011 provides a great improvement.

In previous versions of Microsoft Dynamics CRM if we wanted to store this data inside the CRM System, we would create a new entity, a zip code lookup entity as it were, which only stores a list of zip code and their associated city and state, but has no relationships. We would then populate this entity with all the zip codes and then access it via JavaScript and Web Services to retrieve the data. There is quite a bit of data handling going on including authentication, data requests and result parsing, not to mention an entire CRM entity with data that will almost never change. There must be a better way!

In Microsoft Dynamics CRM 2011 there is a new feature, Web Resources, which we have mentioned in other blog posts. One of the Web Resource types that is available in the Data (XML) resource. Using the Data (XML) web resource an XML document containing all the zip codes and associated city and states can be uploaded into the CRM system. This resource is given a static URL that can be access by JavaScript, Web Pages or XAML elements running on the client system.

Using the Web Resources in Microsoft Dynamics 2011 and client side JavaScript, the XML file can be read and searched with a simple XPath to find the XML Node with the correct city and state. The data can then be placed onto the users form. This method reduces the amount of overhead vs. access the web services for the same data.

The Data (XML) Web Resource is editable and maintainable, yet doesn’t require the same complexity and overhead as an entire Microsoft Dynamics CRM entity. The Data (XML) Web Resource can also be packaged and deployed as a part of a Microsoft Dynamics CRM 2011 solution, which when paired with the associated JavaScript, makes for a very portable solution. The Data (XML) Web Resource is an excellent solution for storing and accessing nearly static data for your Microsoft Dynamics CRM 2011 system.

For more information about technical issues concerning Microsoft Dynamics CRM 2011, or to talk with someone from our expert custom development team about Microsoft Dynamics ERP or CRM, SharePoint, .Net development and more, please send me an email at


By The TM Group, a Michigan Microsoft Dynamics partner with dual Gold competencies for Microsoft Dynamics CRM and Microsoft Dynamics ERP, as well as Silver competency for Portals & Collaboration.

1 thought on “Now You Can Handle “Nearly Static” Data with Microsoft Dynamics CRM 2011”

  1. What about the overhead of loading an XML file containing the data of 42,000 ZIP codes (which I suppose would be a number of Megabytes, especially considering that XML is not a particularly concise way of representing data) over the network (or even the Internet) into the user's browser and parsing it client-side in inherently slow JavaScript, as opposed to a short FetchXML query that lets the powerful database server do the main work ?

    I certainly see the benefit of being able to use web resources for near-static data, but this seems to be a rather impractical example.

    Am I missing something ?

Comments are closed.

Show Buttons
Hide Buttons