Incorporating email into CiviCRM

Integrating CiviCRM with an email client (specifically Outlook) has been a long requested feature. Unfortunately we dont really have any internal windows expertise to make this happen (for now). For now, we've built some code for the HRD project that attaches incoming email as an activity to the contact record of emails that are in the from / to / cc / bcc fields (we create a contact record if not found) We are currently using ezComponents Mail library to read and process incoming emails. If possible i'd like to transition this to using the Zend Framework, since that will be our basic library framework for CiviCRM v3.0. The current approach is file based. The cron script takes a directory argument. The directory contains all the mail files that need to be converted to a CiviCRM Activity. On completion, the mail is moved to a date-stamped processed directory or error directory depending on whether the conversion was successful or not. The libraries for parsing email are quite powerful and easy to use. Each email is broken into smaller parts and attachments are stored as files. We've separated the mail parsing code from the activity creation code, so other components could potentially use the mail object for other purposes. Activities now have optional file attachment(s) (this was a generalization from our earlier 2.1 attachments to CiviMail issue). All email 'file' attachments are stored as activity attachments. Using the above libraries, it should be quite easy to add a layer to retrieve email from a pop or imap server. Would be great for someone in the community to step up and submit code to process email(s) from imap and pop accounts. I'm not sure whats required to integrate this with a desktop client. I suspect a modification of the script that accepts an email as a POST message will makes things easier. Please contact us if you have any interest / expertise in this area and willing to contribute a few hours to make this happen

Comments

I see two usages:

One help desk (cf. eventum):

help@crm.example.com

Any of these help emails can be automatically assigned to a civicrm user "responsible":
from=contact with the activity added
responsible=assigned to
(a notification email has to be sent to the responsible)

One "memory":
For every important email, I can BCC (or forward) it to track@crm.example.com
The Added by is the sender, the contact to add the activity is a bit trickier to guess probably, especially if they are several emails in the to/cc field.

What was your idea ?
X+

1. http://ezcomponents.org/docs/api/latest/Mail/ezcMailImapSet.html

so instead of reading the file, read from the imap box. You might need a db table to keep track of what emails have been already processed

2. Note that in activity the target and the assignee can be multiple contacts. I suspect different "email" processors will want different rules on how to store the to/from/cc/bcc in the above set. We should make this more flexibile in the civicrm_activity_process_email class and allow the calling function to set what goes where

lobo

Is there any thought being given to integrating with Google Apps? Since the education edition ( which includes phone support ) is free for any registered non-profit, CiviCRM + Google Apps would make a great combination.

but would be a great community contribution :).

Any thoughts on what level and type of integration can be done?

I looked through the API documentation for Google Apps at http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html

and think there are 3 main areas that CiviCRM could integrate with.

First, CiviEvent could use the Google Calendar Data API to create new events, edit or delete existing events, query for events that match particular criteria, publicize upcoming events by programmatically adding them to Google Calendar.

Second, the CiviCRM functionality for managing groups of contacts could be extended to create/maintain email distribution lists within Google Apps. I'm not sure how much overlap there would be with CiviMail. But CiviMail doesn't work well for folks on a shared webhost. Google provides PHP APIs for all CRUD operations related to email distribution lists.

Third, there is a "Google Spreadsheets Data API" that allows a program to do all CRUD operations on Google spreadsheets. This may be a way to create "pretty" reports out of CiviCRM without requiring Java on the server, which is now the case for CiviReports.