Our experience shows that before launching an integration project, it does make sense to clearly identify the purpose of synchronization and consider “user-oriented” approach as opposed to the pure “developer’s” approach.
Quite often, a personal productivity tool (e.g. MS Outlook) is treated as a full data set which can be synced with a CRM system “as is”. In reality, however, Outlook is a much smaller subset of information comparing to CRM, so syncing these two apps should be done adequately and with all the possible pitfalls in mind. It’s important not to simplify synchronization task to “what-developers-can-do”, but keep it up on “what-users-need” level.
Hence, on the one hand, we should keep Outlook native, fast, and reliable, so users can still utilize it and love it. On the other hand, we should accurately bring all the necessary CRM data and expose in Outlook without overcomplicating it. Assuming that CRM system may host millions of records and have a pretty complex logic, it’s kinda challenging to integrate and synchronize it with Outlook in a proper way.
A quick example – if there are only 10 records to sync between Outlook and CRM, querying records from CRM will most likely affect Outlook performance (because there are millions of records on the CRM side), and your users will most likely complain and stop using such integration.
We summarized our development experience to share the list of 6 pitfalls that can potentially put your integration project at risk. Just keep them in mind ;-).
- Storage difference
Outlook is a “plane” application with no linked objects per se, which is not applicable for a CRM – all the data there is super-linked (not only 1:M, but quite often M:M). Once you integrate CRM data into Outlook, you should worry about linked objects and care about links consistency. - Performance
Users do not want you to slow down their Outlook. If you do it, they will ignore your tool. Thus, you either make everything work really fast (querying records, building snapshots for synchronization, and processing synchronization itself) or make it invisible for end users, so they do not feel the difference. - Security
Apart from CRM security rules, there are also plenty of cases when users treat their Outlook data as personal and doing everything they got used to with their private data, including deleting entries. Obviously, a CRM won’t like it, so your bi-directional synchronization should be smart enough to find a balance here. Needless to say that synchronization should work with both Personal/Enterprise environments without compromising data integrity in either application - Boarding/Onboarding
While doing the first sync, it’s important to keep in mind that both systems may have already been logically linked- e.g. contacts, emails, tasks can be stored in both apps. So, the challenge here is to bring all the data together without creating duplicates. In most cases, this would be a one-time operation, but it is so important that can waive the integration benefits. - Duplicates
This is an ongoing task, since duplicates might appear after each sync session. Of course, we should think about automatic duplicates/conflicts resolution, but at the same time we need to remain flexible enough so that both end users and CRM admins could tune the way conflict resolution works. - Perception
This is about actual user perception of the synchronization process. It shouldn’t violate a normal workflow with the application that is being synced; and users need to understand what actually happens during the synchronization, and see what they expect to see after the synchronization is done, etc.
These are the challenges that we met on our way to developing the integration platform as it is today. Some have been resolved during the pre-production; with the rest of them we’ve been fighting for quite a while. But understanding the following several things helped us a lot:
- All the CRM data is hierarchical and we shouldn’t destroy this hierarchy while bringing data to Outlook.
- Most users treat synchronization quite carelessly. E.g. they could close their laptops while there’s a synchronization process running in the background. This means that we, developers, should keep this in mind.
- Synchronization should be bi-directional whatever it takes, since there’s a million of various use cases which we can’t predict, but need to cover. The best way here is to think of users doing anything they want in both applications, and make them capable of doing that effectively. Do not limit users’ flexibility in doing things in their apps, and they will not limit their love to your integration solution ;-).
Each of the 6 areas listed above deserves at least one dedicated post. We will post more, explaining what exactly the challenge is and how to protect, prevent, and overcome. So stay tuned for the next piece of information on Storage and do not hesitate to share your questions/comments with us!
