You need to know your stuff in a Dynamics CRM integration. We’re following on from a recent post where we shared some lessons we learnt from integration work we did with a tech non-profit. This work included integration of:
- Ensemble and Cache as a central database
- Microsoft Dynamics CRM containing historical and ongoing sales and marketing data
- A bespoke web portal for processing data and requests
- BMC Remedy for call centre management
So today we’re talking about Microsoft Dynamics CRM… here are some essential points for you to consider:
1. Accessing Dynamics is not as straight-forward as you may think
Microsoft does not allow Dynamics clients to develop code that makes direct access to the product database as that may incur in the solution being no longer supported.
It also requires a Microsoft-certified professional to develop the logic that makes access to the C#-based API the product exposes.
There is therefore a market of solutions that provide intermediate APIs that simplify the task of accessing the native API.
2. Trigger-based web service calls
Dynamics provides a plugin that allows it to make a web service call every time a record is created or updated.
This turns out to be one of the easiest ways of integrating Dynamics with other systems with that plugin allowing for specific fields to be sent and the endpoint URL to be set.
Dynamics then sends a SOAP envelope containing the name of the entity (e.g. contact, account, opportunity), the operation (e.g. create, update), a list of attributes (e.g. name) and respective values.
The problem with this approach is that the target system usually ends up receiving much more data than what would be necessary as every operation executed by a user against that entity will fire the web service, sending extra information that is possibly unnecessary for the integration.
A second and possibly worse problem is that each call only sends the data relative to a single record and not the data relative to the records that it has a relationship with, so the target system may need to persist the first record (e.g. contact) until it receives a second call containing the second record it relates to (e.g. contact account).
3. Dynamics may be slow for high-volume data loads
Web services are definitely not the best technology for high-volume data loads, but in case that strategy is necessary, Dynamics’ trigger-based web service calls may take a long time to be fired up as that is the usual behaviour it has for high-volume data exports.
4. Dynamics is configuration-based
As Dynamics administrators are usually tied to the Dynamics configuration interface, it’s usually not easy for them to implement complex pieces of logic as one would do with imperative programming languages.
5. Dynamics may be too permissive
Dynamics allows users to create multiple instances of an entity (e.g. account) with the same name. That may not be desired when integrating with other systems that expect these names to be unique.
It may therefore be necessary to cleanse the CRM data before the integration takes place or to group entities under a parent one so that the parent record is sent out.
6. Different instances of Dynamics may generate different SOAP envelopes
If a company makes use of different instances or even different versions of Dynamics (for instance, if each of its branches has a different instance), they may generate slightly different SOAP envelopes when invoking external systems.
Although this may not come as a surprise, it should definitely be taken into consideration when integrating with Dynamics
Does your company use CRM Dynamics or need to integrate with any of the above systems?
These are just a few of the many applications we work with on a regular basis. We specialise in IT integration, so you don’t need to develop your own integration experts, as we can do it for you.
Contact us to find out if one of our solutions would work for you. We have expertise across Healthcare, Financial Services, Public Sector, Retail and Utilities.