As I talked about in my last post, there are a variety of strategies one can use to move data between your CMS and your CRM. I’m going to choose a few examples to look at in some depth. Some of these are examples I’ve been working with clients on, or I’ve played with, some are just examples I know about, but are prominent, useful examples to talk about. I’ll talk a bit about mechanics, and talk about strengths and weaknesses, and under what situations you might want to look at it. I’ll cover:
- CiviCRM/Drupal (with Joomla notes)
- Plone/Salesforce.com
- Using varied webforms (like DemocracyInAction, Blackbaud, Network for Good, etc.)
- Drupal/Salesforce.com
- Joomla/Salesforce.com
You’ll notice that only Drupal, Joomla and Plone are represented among CMS. That’s mostly because that’s what I know, and there is a critical enough mass for all three of them that some integration work has been done in a systemic way (the exception to this is Drupal/Salesforce – it’s only half-way systematic.) I haven’t included any all-in-one systems (like Kintera), mostly because I don’t think they are a good idea – you might get a halfway decent CRM, but you’ll for sure get a crappy CMS, and there is no good reason for that. Another note: I’ll talk about this in detail later, but Salesforce also includes the new Salesforce.com app, Common Ground, by Convio. From what I can tell (I’m learning a lot more fairly quickly) integrating Common Ground with a CMS should be pretty much the same process as integrating Salesforce.com.
First up, CiviCRM/Drupal. I’m choosing this first because it is a pretty interesting example, and also is an example of what I would call easy and tight integration.
Tagged as:
CMS,
CRM,
integration,
web
If there are two acronyms that are at the center of nonprofit communications, it’s these two, CRM (Constituent Relationship Management – and I’m making this broad enough to include fundraising) and CMS (Content Management System). And because of this, it makes sense that integration of these two is something that is a need to be filled. What’s involved in this?
First, the what – what to integrate? Most often nonprofits want to capture information from web users. That sort of information could be a newsletter sign up, a contact form that should be responded to, an online donation or an event registration. The organization wants to capture the demographic details, as well as make sure that data is synchronized with the data they might already have on that web user, so they can track their constituents over time. In addition, sometimes nonprofits want to expose data from the CRM to the CMS. One purpose is to allow users to modify their own information (if the site allows logins.) Another purpose is for membership lists, or group lists, or perhaps live tracking of donations from a specific campaign.
There are four strategies that can be used for this integration:
- Manual. The old fashioned form of integration. Forms sent go to email, or a separate database, and someone manually enters that data into the CRM. Data from the CRM is manually reported and put up on the CMS. It’s amazing how much this still needs to be done. Some CRMs still don’t have openAPIs. Even if they do, it takes developer time to write the code to do the integration, and that may be resources that a nonprofit doesn’t have.
- All-in-one. Some vendors have products that provide integration by having both the CRM and the CMS together. Trade-off – you don’t get best of breed tools for both. Second trade off, all of these are proprietary.
- Web forms from CRM vendor. This is integration of a sort. One sets up a page (often donation or event page) on the CRM vendors web platform and link your page to their pages. Or, one pastes HTML code for a form into one of the pages of the CMS, and when the user clicks “submit” the data actually goes to the CRM vendor.
- Integration. This is when actual code is written in the CMS (via module or customization) which calls APIs on the CRM side to perform specific actions, such as adding records, syncing records, grabbing data, etc.
All of these strategies take time and resources, but of different kinds. Some take internal staff resources (especially the Manual strategy.) Others take developer resources (especially the Integration strategy.) Depending on the CRM, some require additional license fees for forms or APIs.
So what’s the right strategy? That totally depends on a few factors. First, are you happy with your current CRM and CMS? If so, what specific types of integration do you want to have happen? What are the specific tasks and data types you want to move between the CRM and the CMS? The best way to accomplish those tasks depends primarily on your CRM, although if you are using a proprietary CMS, a hosted CMS service, or an older CMS, you might run into trouble with integration.
If you are in the process of reassessing your CRM or CMS or both, now is a very good time to think hard about how you want these two to talk with each other. I know that’s one more thing in a long list of considerations (and it’s generally more important to think about for the CRM – the CMS, if it is modern, and especially if it is open source, will provide few barriers to integration.) I’ll have follow up posts on specific examples of this integration using open source tools (on one end or the other, or both.)
Tagged as:
CMS,
CRM,
nptech,
opensource
A while ago, I joined a bunch of groups at groups.drupal.org, thinking I’d pick up some interesting ideas, and meet some folks who were doing cool stuff with Drupal. One of the groups I joined (along with “Drupal for Good” and “Drupalchix”) was the PostgreSQL group.
Yesterday, in my RSS feed, this post showed up. It was the suggestion to remove PostgreSQL support from the Drupal core.
I was always aware that Drupal supported PostgreSQL, and I didn’t really have any plans to use it. And there are varied opinions as to it’s usefulness (which I beg to differ on.) But as a long time lover of PostgreSQL, I couldn’t let this drop. And, I’d been looking for a good solid project to get me going in Drupal, so it looks like I found it. So I’ve adopted it.
But, it turns out that with Drupal 7 (the development branch) it’s virtually impossible to install Drupal, and even though I did wrangle an install (all of the right tables seem to show up in the database), it doesn’t actually work, and I can’t yet figure out why. I don’t yet really grok the structure of Drupal, so it feels like sorting through spagetti right now.
There are several core modules with PostgreSQL problems in Drupal 6, so I might actually go back and work on those first, before I can think about tackling what’s wrong with install.php and PostgreSQL.