E-mail
Summary
The CiviCRM team is excited about the opportunity to collaborate with Green Media Toolshed in developing it's new Media Contact Manager (MCM) application. We have reviewed the high-level specifications in the RFP and feel that there is a solid technical and business basis for building MCM on top the CiviCRM platform:
- The MDB and CiviCRM data models are significantly compatible
- Core CRM requirements from the RFP match existing CiviCRM functionality
- CiviCRM / CivicSpace integration will support GMT's evolving content / user integration requirements and design customizations
- Almost all of the MCM requirements that are not currently available in CiviCRM are already on our road-map and will benefit our current and targeted user communities.
Given the tight deadlines for this project, existing CiviCRM team commitments and resource constraints - we think the following would be a good way to structure responsibility for this project:
- Based on a funding agreement with GMT, CiviCRM would commit to completing all required platform enhancements on an accelerated time-frame. The next section contains a first cut at defining these requirements. Funding requirements can be nailed down after we get more details on the requirements and areas where there is room for compromises.
- GMT would "own" Project Management responsibility for MCM. This probably would entail engagement of a part or full-time Project Manager.
- GMT would provide one full-time experienced PHP engineer. This person would be responsible for implementing GMT-specific modules (primarily the MDB <-> MCM database initialization and synchronization functionality). They would also contribute to GMT-related core CiviCRM development as available and needed during the project. CiviCRM will provide consulting support to this person as needed to get them up to speed on the platform and collaborate on implementation approaches.
Platform Enhancements for MCM Implementation
We reviewed each of the requirements described in the Features section of the RFP relative to current and in-progress CiviCRM capabilities. The areas which appear to require platform enhancements are discussed in this section.
1. User / Group Model
CiviCRM currently leverages Drupal's matrix-style Role / Permission model to control access to general CRM functions (e.g. add/edit contacts, administer configurations, add groups, etc.). Access to specific sets of contact records can be constrained by associating a group of contacts with a role.
The ability to limit access to subsets of data for a given contact (e.g. interactions between that contact and a user or group of users) is not currently supported. Nor is the ability to define tiered (tree-style, inheritable) permissions. We have developed a draft specification for hierarchical ACL (access control list) permissioning which we believe would be flexible enough to accommodate MCM requirements. We would like GMT to review the specification so we can evaluate this fit together.
Access Control List Permissioning Specification
2. MCM Database Instantiation and Synchronization
This general requirement includes mapping of the MDB data model to CiviCRM, instantiation of new MCM data-stores and bi-directional synchronization between the master MDB and MCM's.
2.1 Data-model Mapping
Based on the UML layout, we think the MDB schema maps directly to the current CiviCRM data model with a few exceptions. The "Jobs" class is one area where we will need to understand the requirements and use cases better in order to determine whether extensions are needed. Our first take would be to model an MDB Job as a CiviCRM Relationship - and then assess whether we need to enable Locations for Relationships, or whether the CiviCRM model of linking Individual Contacts and Outlets (Organizations) to Location(s) is workable.
It looks like there are only around five "custom data elements" defined in the UML (i.e. data not included in our core model). Given this, our "skinny-table" implementation for custom data seems workable.
2.2 Instantiation
CiviCRM currently includes a flexible user-driven CSV import which supports core, and custom contact fields as well as activity history and relationships. However, instantiation of new MCM data-stores will probably require some import optimizations and possibly a scriptable command-line import option (in support of an automated install/instantiation sequence). These enhancements would be added to the CiviCRM core.
2.3 Bi-directional Synchronization
The primary effort here will be creating a separate GMT-specific module which handles the data "conversion" for outbound and inbound updates. The platform already includes the building blocks for that this process will sit on top of. There is support for invocation of CiviCRM "hooks" in other Drupal modules which will be used to trigger the MCM to MDB sychronization events. We have also implemented inbound and outbound SOAP calls ("server" and "client") for interactions with PayPal, Yahoo Maps and between CiviMail and CiviCRM. CiviCRM engineers would probably do a "reference" implementation of the synchronization model and then advise as needed on the full implementation.
3. Bulk Communications
The CiviMail component of CiviCRM should service most MCM Email bulk communication requirements, including mail merge/token replacement, bounce handling, click-thru and forward tracking. CiviCRM does not have support for fax bulk communications - but the CiviMail architecture would provide a good model for adding this feature. Alternatively, this could be handled by exporting a search result set or "list" to a 3rd part fax server.
4. Search
CiviCRM's provides an Advanced Search capability which supports ad-hoc and saved searches on core and custom contact properties as well as activity history. We would likely want to extend this to support searching by Relationship as well as a proximity search capability (e.g. find contacts with X miles of a given postal code).
5. Activities
CiviCRM's Activity History class is a flexible data-store for interactions registered by CiviCRM functions OR by external modules. However, activities are not currently "nestable". The work-flow and processing of contact 'responses' to bulk communications is an area that needs further exploration. Currently this would have to be done as a manual task by the user for cases like email replies to bulk mailings.
6. Dedupe work-flow - dupe flagging, review and resolution
CiviCRM currently supports configurable duplicate matching rules. By default, duplicates are identified based on matching FIRST NAME + LAST NAME + EMAIL. This rule can be modified to include any combination of core and custom contact properties. We will need to update this framework to support OR rules and grouping, as well as the ability to define rules for different classes of contacts (e.g. individuals vs. organizations/outlets).
Batch duplicate flagging and reconciliation is functionality as described in the RFP is functionality that will need to be added to CiviCRM for this project.
7. Design / URL Access
MCM Group ("instance owner") design customization will be handled by CivicSpace/Drupal platform - with CiviCRM automatically inheriting the visual framework, logo, color-scheme, etc. Options for site URL's will need to be explored as part of the CivicSpace multi-site ("ASP") provisioning architecture.
Next Steps
We think it would be worthwhile for GMT to spend some time "trying out" CiviCRM on our demo server and we would be happy to provide a tour-guide. We also think it would be useful for folks to download and install a local copy and experiment with customizing CiviCRM to handle some MCM tasks.
We also would suggest scheduling a follow-up call or meeting to detail out the platform enhancement requirements a bit more and discuss and develop a mutually agreeable approach for collaborating on the project.
