CRM Integration considerations

Every CRM solution has to be integrated with in-house applications in addition to other systems like Microsoft Outlook, Microsoft GP etc in order to leverage most out of CRM. In this blog I will give a generic overview of how to go about the whole integration exercise. This blog covers integration with custom applications and the series would continue to cover integration with Microsoft GP and other products.

Microsoft Dynamics CRM 4.0 features a couple of web services, so that using these web services one can easily talk to CRM. Now that WCF and WWF is replacing integration products because of its reliability, scalability and robustness so I think that is the solution one should consider for CRM integration with other applications. CRM has following out of the box services.

  1. CRM Service
    – This is used to interact with the entity instance data.
  2. MetaData Service
    – This is used to interact with the entity model.

CRM Service is where all the action takes place, this is our (for the outside world) interface to CRM. It might feel tempting to just directly access the CRM database and do all the stuff but that’s neither supported nor a recommended approach. Whereas the MetaData Service is used to retrieve all metadata, add/update attributes in entities or add/remove an option from picklist etc.

Some common methods for CRM Service are as follows:

  1. Create
    – Creates an instance of any entity that supports the Create message, including custom entities.
  2. Retrieve
    – Retrieves an instance of an entity.
  3. RetrieveMultiple
    – Uses a custom query (QueryExpression) to retrieve strongly typed results.
  4. Update
    – Updates an existing entity instance.
  5. Delete
    – Deletes an existing entity instance.
  6. Fetch
    – Use a custom query (FetchXML) to retrieve results in XML format.

Another important method is the Execute Method which is message based and is used for specialized business logic.

Now that we have some basic knowledge of the services that will help us talk with CRM, let’s start talking about integration. Suppose we have an existing application that is used for operations that affect the way we manage our customers. It could be an application that is used for membership updates with each customer getting different level of customer support based on membership.  Ideally this system should be integration with CRM so that sales team is informed on membership/membership updates to perform operations that would guarantee greater level of customer satisfaction.  Similarly we would like the CRM solution to be integrated with other applications so that changes in one system are reflected in the other.  Another example is registration on site that might lead to creation of lead/account in CRM so that sales team could talk to customer/potential customer. Without going into the intricacies of your integration requirement it is evident that CRM needs to be integrated with other application and an architecture that offers de-coupled, SOA model of integration would suffice for most of integration requirements.

Normally the integration results in a two-way communication between CRM and other applications. Let’s take the example when a registration process should result in the creation of lead/account/contact or opportunity in CRM. In this case an action in custom application results in something happening in CRM. Same is to for many operations happening with CRM that should update the other systems.

Let’s identify the building blocks for our solution. For our existing system to talk with CRM we already have the CRM Service, but for CRM to talk to our existing system we’ll need to have a service as well. Let’s call it CRM Integration Service.

Considering that one would like to integrate the two systems using WCF it’s obvious that the existing application architecture needs to be extended to expose some of the operations through a WCF contract. We do it by adding an integration helper. This will be completely responsible for all the integration calls from our existing system to CRM. In case there is no requirement for the response from CRM for the operation resulting from custom application one would have one-way calls in our new CRM Integration Service and we’ll execute service calls on a separate thread from thread pool, so that our normal flow of application isn’t disturbed.Any exception will be handled in that separate thread from thread pool.

Our CRM integration service should meet following requirements.

  1. It should have no impact on the existing application. This is important because in case one ends up changing the existing application you would have to go through the complete testing and deployment cycle.
  2. The integration should be configuration driven so that the channel could be closed between custom application and CRM.
  3. Error handling in the integration layer should not affect the application that is responsible for invoking the operation.
  4. Integration layer should be robust which means in case of failure it should be able to restore and sync up the two systems.
  5. Scalability can be a concern but it is driven mostly by the traffic and the direction of that traffic. I will not talk much about it in this series.
  6. Unit work performed by integration layer should be small. This is very important and I will write more about this in my next blog.

These are some of the integration considerations for any sort of integration. Having worked in EAI and B2B integration projects, I know through my experience that these are absolutely critical requirements for the integration to work.  In the next post we will discuss how our integration solution would cover these requirements. I will also share some code and requirements/problems that we addressed as part of our implementation.


Onsite resource in offshore model

I have been working from the offshore office as part of offshore delivery team for years. However for almost two years now I have been working onsite with our customers managing project delivery using offshore team. Learning from my experience i have prepared a list of Dos and Donots for the onsite resource in the offshore model. Good news for all the offshore developers is that as per my analysis the success of 90% projects , impemented with onsite-offshore blend, is dependent on the onsite team manager / business analyst. However this does not imply that onsite resource should take all the credit for a successful delivery because a project can only be succesful if offshore team delivers quality in the estimated time. Here are some of the key points regarding the onsite resource’s responsibility.


This is the most critical aspect of software project delivery. As it has been documented time and again so i will not go into the details. However with onsite-offshore blend the requirment gathering phase becomes even more challenging. In this model its not only the requirement gathering and documentation that is critical but also the communication. Onsite resources must understand that offshore resources do have direct access to business users and they can only develop what has been communicated. Offshore resources can raise only a limited questions given the project timeline and thus Onsite resources must make sure that requirements are not only gathered correctly but they are also communicated and understood by offhsore team.

Project Delivery:

Depending upon the nature of project, onsite manager must drive the delivery process not only in terms of project management but also interms of some of the key technical decisions. Most of the projects are either an extension of an existing application or  in case of new applications  they involve some sort of integration with rest of the applicaitons. In either case there is a requirement for the offshore team to understand the existing architecture and re-use the functionality already available. As the offshore team is mostly on its own to understand the existing code (often without documentation) the Onsite resource must play a very important role in responding to the questions and making sure that offshore team follows the same standards and conventions. If onsite resource does not have the technical background then this becomes really challenging. It might work for businesses where the project is outsourced but in case the modules by offshore team are developed in conjunction with development by onsite resources then it is even mor important to have the process in place for the test case verification and code reviews. It is often a good idea to  involve the onsite team as well but then the whole purpose of offshore is to take work load from onsite and get it done offshore. Onsite resource must make these decisions upfront to manage client expectations and quality of project delivery.

Lead generation:

Another important role often given to onsite managers is to make sure that they generate more business for their company. More business either in terms of continuation of projects or maintenance work. Onsite managers work on this in different capacities but from my experience here is what i believe works best. Onsite Managers / analysts should wear just one hat when they work for client’s on premises and that is ‘Client’s employee hat’. Onsite resources should forget about the company they are employed by and about the interests of that company. This way onsite resources slowly builds the trust of the company they are contractors for which is the most important thing in my opinion for the long lasting relationship. If the trust is there and Offshore team delivers quality then the account would autmatically grow. In addition to this one more thing that the onsite resources must do is to make sure that client knows about all the services that they themselves or their company offers. However its easier said than done as while communicating such things the client must get the impression that its being done in their best interest and not as part of sales activity for the employer.

Honesty is the best policy:

To conclude i would just say that for a long term relationship honesty is indeed the best policy. Honesty in work does not imply that one should be blunt in communication. Its implication is just that one should always be fair to the client and raise concerns and questions about all the problems in the organisation like an employee. Politics and culture varies in each organisation and onsite resources should be able to understand and counter it but again in a way that the actions are driven by the all important goal of greater client satisfaction.


Last but not the least is patience. Normally it takes time to build a relationship and even more time is required to get results so haste with offshore-onsite blend would certainly result in waste. More than the onsite resources the consulting company should understand this. Onsite resources must also understand that good relationship with client and quality deliver would result in on going business but only if client has the finances and projects. So one should keep an eye on the financial situation of the company as that is eventually the primary source for business generation be it onsite or offshore.