Our team recently took on a client that had several Microsoft Dynamics CRM 2011 online deployments. Due to this particular client’s complex business model and wide range of verticals, segregation has been required on every level of the project. When we were contacted to setup another Dynamics CRM deployment on their behalf, the fairly self-sufficient client told us that he failed to move a Dynamics CRM Solution from an earlier deployment to the newest deployment. Once I got in their CRM system and started digging around, I discovered why he believed the solution import had failed.

This is my third blog in a series concerning data integration. In my first two blog entries we overviewed some of the data integration hurdles as well as some of the common methods used to discover the net-change data that will need to be translated. Here in my third blog I’ll discuss some of the benefits of not integrating in real-time, but creating a batch job to perform the integration. We’ll also look at the Business Rules that may need to be applied within the integration process.

In my previous blog focusing on the hurdles of real-time, two-way data integration, I highlighted the hurdle of how to discover the data you need translated. In most cases, discovering the net-change data is all you want to translate on a real-time basis. Remember, a two-way integration means net-change data going in two directions or more (depending on the number of systems you’re integrating) at a rate determined by how many end-users there are on each of the systems being integrated. Business systems with a significant amount of end-users can create substantial volumes of net-change data.

In some cases, if not all too some extent, integration between Dynamics™ CRM , Salesforce® or/and SharePoint® with your back-office system is the key to user adoption. Real-time, two-way data integration allows all segments of the business to access the very latest transactional data, and the information that the data contains.