Integration with Microsoft Outlook

Microsoft Outlook plugin consists of the following features

• Integrate outlook contacts with civicrm contacts (including addresses and phone nos)
• Integrate outlook meetings/phonecalls with civicrm meetings/phonecalls

Integrating Contacts

Outlook/CiviCRM contacts will be tightly integrated on the following fields

• first name
• last name
• nick name
• email(s)
• address
• phone(s)
• im
• home url

Integration would involve adding Outlook contacts to CiviCRM and vice versa.
The following scenarios are envisioned

Scenario 1

1. fname1, lname1 added to Outlook.
2. synchronization with CiviCRM requested.
3. fname1, lname1 dont exist in CiviCRM and hence added to it.
4. Outlook deletes contact fname1, lname1.
5. synchronization reqested
6. We can either delete fname1, lname1 from CiviCRM or add it to Outlook (this could be determined by mapping tables or using the source field in civicrm_contact).

In scenario 1 the decision to add fname1, lname1 to Outlook is incorrect since it entered CiviCRM through Outlook and since the source has deleted the contact hence CiviCRM should delete the contact by default (unless the user chooses the option of CiviCRM winning the conflict).

As seen above the Outlook sourced contacts drives the changes made to mapped contacts in CiviCRM (as default action which can be overriden by conflict prompting mechanism).

Integrating Meetings/Phonecalls/Notes

Potential Schema

CiviCRM schema would need to have some sort of mapping tables which would map each CiviCRM entity with Outlook entity.

Currently civicrm_contact has a field 'source' which could be used to keep track of contacts imported from Outlook.

Similar mapping needs to be done for tables which store notes, phonecalls and meetings.

For more finegrained mapping (or when changes to CiviCRM entities will be logged) it would be advisable to have seperate tables for mapping the entities with the source and have timestamp data with it.

Coding Tips

We plan to use the open source Vtiger Outlook plug-in as the starting code base. The code is written in MFC and uses ATL.

From a newbie coder perspective the code would be split into the following logical compartments.

1. Read Outlook contact data.
2. Send Outlook contact data to CiviCRM (via SOAP as used by Vtiger).
3. Receive new data by CiviCRM synchronization server.
4. Update Outlook data.

From the above it can be seen that 1 and 4 could very easily be reused. 2 and 3 would require extensive coding.