In one of our recent posts, A Closer Look at Integration, we have explained why “the right” Outlook integration should always support the full and bi-directional data sync between an application and Outlook. This means that Outlook will have to accept and store the data Outlook isn’t “ready” for and might not have relevant fields and forms.
An example – it would be more logical for Salesforce users who synchronize Contacts with Outlook add to the default Outlook’s Contact form such SFDC fields as Company, Description, Notes, Opportunities, Tasks, Account Name.
With this in mind, it’s quite obvious that in order to properly combine and connect all the data, Outlook has to be extended by adding:
- New fields to existing Outlook objects;
- New objects that will match relevant CRM objects we want to bring down to Outlook (i.e. Accounts, Leads, Sales, etc.).
So, let us share the possible ways of implementation we consider the best to support all the needs stated above.
First of all, we would recommend leveraging the depth of MAPI system Outlook is built on, since it offers more features than a high-level Outlook API – OOM (Outlook Object Model).To create a solution that will work with the system directly, we need to utilize C++. Applying any other language will require third-party adapter libraries that will only add one more level of complexity and may potentially be buggy and not up-to-date with MAPI.
The limitation here is also based on the fact that MAPI is poorly documented and it’s only been a year since Microsoft began to reveal its details, so be prepared to some bumps on this way. Still, our experience says that this way is the shortest and hence the optimum one.
So, what should be done to extend Outlook data model and UI through MAPI?
Every Outlook object has its own message class stored in a specific field and called PR_MESSAGE_CLASS. Analyzing it, you can:
- Determine the UI form this object has;
- Determine the set of custom fields this object has;
- Select objects of a certain type by filtering by this field.
There’re several main message classes in Outlook:
- IPM.Contact;
- IPM.Task;
- IPM.Appointment;
- IPM.Note;
- IPM.Document .*, where * is an attached file extension (doc, txt, etc.).
Obviously, Outlook does not know anything about such objects as Account, Lead, Opportunity, and so on. Moreover, the object type IPM.Contact, for example, has a non-extendable list of pre-defined fields. Therefore, to add some additional business information to those objects, we should sub-class them.
Our basic rule for forming such a subclass is [Built-in class].[Product Mark].[CRMD type].
Built-in class is one of the Outlook main message classes outlined above.
Product Mark is used to identify different CRM products; for Oracle Siebel it would be SBL, for Salesforce SalesDesktop – SD.
CRMD type is the name of a CRM object type (For example, Account).
Thus, Account in the SFDC project, built on the basis of Contact, will have the full class value of IPM.Contact.SD.Account.
In most cases, we sub-class Contacts because of the several reasons:
- Its behavior is less dynamic. I.e. it doesn’t change its form as Task, Appointment, or E-mail does after hitting Reply, Forward, Invite Attendees and so on;
- It is weakly associated with a built-in Outlook Activity processing;
- In addition to the custom fields creation ability, it also has 4 built-in fields to store custom data in. Sometimes it really helps with resolving specific tasks.
Once form is sub-classed, we’re pretty much free to do with it anything we want ;-) Moreover, we could utilize a newly sub-classed form to display melded or new objects of any complexity.
Actually, there is another way which allows displaying custom forms in Outlook – implementing a so-called Form Server. Its forms selection is also based on the rules described above, but these forms have to be implemented from scratch (and even the toolbar buttons need to be re-designed). Too much work, that’s why we’d better use the one described above.
Today, InvisibleCRM technology has all this encapsulated within our SDK and doesn’t require using MAPI and repeating steps described in this post. It’s all being done automatically with Outlook modifications described in XML and data delivery ruled defined for connector.
