E-mail
In early 2010 an Advocacy Online client was considering using CiviCRM to integrate their telemarketing and direct mail CRM needs with the online petitions and other tools they were using from Advocacy Online. While expensive at over $1000 / month, Advocacy Online had the advantage of already being integrated into their operations and being a proven supplier of accurate information on Canadian parliamentarians. Advocacy Online is limited in various ways that make it inappropriate as a central repository for offline fundraising and advocacy. This project will not be proceeding.
This page is a brainstorming page on how a two way data integration could be implemented to allow CiviCRM to have all of the information in Advocacy Online.
Attached are a number of AO (Advocacy Online) API documents.
One possible architecture is to develop in Drupal a CRUD data access plug-in module for each CRM. These plug-ins could provide a common API for users and transactions of various sorts (forward to a friend, sign a petition, contribute, send an email, click-through an email, etc). I see them as elaborating the civicrm_crmapi.inc in the CRM API Drupal module.
Then one could develop a CRM Sync module that would be told to listen to changes on one CRM and update another with changes using these data layer plug-ins. It could be configured to sync CiviCRM to AO and AO to CiviCRM.
As AO is remote and does not have support for hooks on events, we would need to poll for AO changes.
We may decide to simplify implementation by also using the same polling approach on the CiviCRM REST API to reduce the complexity of the implementation and to support others with CiviCRM implementations that are not running in the Drupal instance that is doing the data synchronization.
Another AO feature requiring support for asynchronous processing is that when a file is uploaded to AO it is queued for later processing, with processing completion currently signaled via an email or determined through polling. This is similar to SalesForce's bulk data upload functionality, and has some merit.
It may be useful to take advantage of Drupal 7's functionality in the areas of Entity API and Faces, but I haven't got my head around exactly how to do that yet or if it makes sense in the end. I like the lazy loading of large datasets possible with Faces, which may involve writing the data access layer in a slightly different way.
Some Drupal 6 modules that may have snippets of useful code:
http://drupal.org/project/civicrm_dia : CiviCRM Democracy in Action - pushes CiviCRM data to Democracy in Action
http://drupal.org/project/civicrm_subscribe: CiviCRM Subscribe - somewhat dated module, but with patch has code to push subscriptions to CiviCRM
http://drupal.org/project/petition: Petition: - posts petition signing actions to CiviCRM activities via profiles.
http://drupal.org/project/activism: email list opt-in, petition and tell-a-friend functionality
