Contact Management with Microsoft Exchange and Outlook
By Brian Pituley
(reprinted by permission of the author)
Contact management and activity journaling have always been an important part of doing business and, in today's increasingly fast-paced world, they are becoming indispensable. Contact management has traditionally been done by individuals and most contact management software solutions are aimed at the single-user market. In today's business environment, however, team work and the requirement for continuous coverage are driving the need for work group contact management and journaling.
Exchange 5.5 scenario
Contact management and activity journaling are a built in functions of Outlook and Exchange server but they are designed to work together for a single person. A single user's contacts are stored on the Exchange server in the user's mailbox. A single user's contacts can be shared but given the security model used by Outlook and Exchange, it is impractical to share with a large group. Contact information can easily be shared for a work group or a corporation through public folders. Activity journaling records are also stored in the user's mailbox and should, in theory, be sharable. The problem is that Outlook cannot be configured to write journal entries to any location other than the user's mailbox. What this means is that even if a given user were to share his journal entries, a second user would not be able to add entries to the first user's shared folder. The second user's journal entries would end up in their own mailbox rendering them unusable unless the second user also shared his journal information. The best possible case is that there would be multiple folders containing journal entries, each one separate from the others. Searching for entries pertaining to a single contact would be time-consuming at best.
It is possible to create solutions for group contact management and activity journaling under Exchange 5.5 but because of the nature of the Exchange database, it is cumbersome to implement and slow in operation. Custom Outlook forms, an Exchange public folder, and a database are all required to make it work. Custom forms allow the use of the familiar Outlook contacts user interface while enabling additional information fields and the addition of stationery-based letters and faxes through integration with Microsoft Office. The public folder is the repository for the shared contacts, and the database and the associated code ties the contacts and journal entries together. The processing for this type of solution is all done on the client PC so the performances of the system is highly dependent on the power of the desktop PC's and the network bandwidth that's available. Because of the reliance on the network, this type of solution does not scale well, and performs especially poorly over wide area networks. There are third-party products like ContEX from Impreza (http://www.imprezacomp.com/contex/index.htm) that perform the function reasonably well but, as stated earlier, they do not scale well.
Exchange 2000 scenario
Creating this type of application with Exchange 2000 will be considerable easier due to changes in the structure of the Exchange information store database. The new store structure, termed 'web store' by Microsoft allows access to stored information through a variety of ways. Where the Exchange 5.5 database could only be accessed through MAPI calls, the web store allows access to all information through Win32, MS Office, and HTTP URL's as well as MAPI. Security permissions must still be granted to files and folders but the multiple access methods allow for much greater simplicity when creating applications that will rely on the Exchange information store. For example, the ability to access individual pieces of information via URL's allows the development of web-based applications that don't have to rely on MAPI calls to retrieve information. In addition, Exchange 2000's full-text indexing capabilities will greatly simplify searching for information.
Any companies that are considering implementing an Exchange and Outlook-based contact management system on Exchange 5.5 should wait until they have migrated to Exchange 2000.
While the infrastructure work required to implement Exchange 2000 is considerable, the ease of application development under Exchange 2000 will more than make the investment worthwhile. Most companies running Exchange have an immense amount of valuable information stored in the Exchange databases, information that is largely inaccessible to anyone but the creators. Exchange 2000 opens the databases to applications like contact management and data mining.
Click here to go back to my OutlookExchange homepage.