CiviCRM was the first nonprofit-focused open source CRM (one of only two, at this moment.) It is a great tool for small to medium-sized organizations who are looking for a CRM to track members and donations, register people for events, and do mass mailings. There are also some other features, like grants management and case management that are more nascent, but promising for the future. I’ve implemented CiviCRM together with Drupal, and I’m really psyched to keep working with this great combo.
CiviCRM originally only integrated with Drupal, but recently a lot of work has been done to also integrate CiviCRM with Joomla. CiviCRM acts in Drupal like a module, and in Joomla like a component. This means that since the code sits in the same exact place, and the databases could even be shared (or not, it’s your choice) in effect, CiviCRM is becoming part of your CMS. You install CiviCRM inside your CMS installation directory, and the CMS and CiviCRM talk to each other through PHP APIs (or “hooks”) (there are some examples of database calls across the CMS/CRM). There isn’t much work to be done by you, or by the person who implements it for you, unless you want to do customizations, and expose CRM data in new and interesting ways. Users in your CMS installation will become users in CiviCRM when you install it, and be synched going forward. You can set up web forms (for donations, event registration, etc.) and have them be menu items. It’s a very straightforward integration.
Using CiviCRM and Drupal is a great way to easily get powerful integration between your CMS and your CRM. They are both installable on pretty standard shared-hosting accounts (although shell access really helps.) It’s a really cost-effective way to get powerful features. The disadvantage of this is that you have to choose CiviCRM and Drupal (note on Joomla below). Both have their disadvantages, and you might have a variety of reasons for not choosing one of them. Jon Stahl, in his comments on my first post in this series said: “a PHP API accessible only to other PHP apps on the same machine is simply not sufficient integration in an age of web services, where people run different apps on different machines and use languages other than PHP for building web apps.” I do agree with Jon to some extent. I do know that CiviCRM has been working on their web services APIs, but a really strong set of them would mean that people could integrate CiviCRM with more CMS, which , from my perspective, would be a Really Good Thing. That said, I do think that this combo would be a cost-effective solution for good chunks of the nonprofit community.
Note: My understanding is that there are still some snags with the CiviCRM/Joomla integration, and I’m not very familiar with it. If you already have a Joomla site (or you are about to choose Joomla) and you want to use CiviCRM, you should talk to the CiviCRM-Joomla folks, or check out the CiviCRM forums. One example: since Joomla doesn’t have granular ACLs (Access Control Lists) there must be issues with how permissions work in terms of access to specific parts of CiviCRM. If you have detailed info, please feel free to share in the comments.
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.
I love NTC (NTEN’s Nonprofit Technology Conference). I would be dishonest if I said I didn’t have a sweet reminiscence for the Circiut Rider Roundups of old. But they are long gone. As fields often do, ours grew up and professionalized. And what has taken it’s place is valuable to a much wider audience (and a much larger one!) And, this year, for the very first time, I live in the same city in which NTC is taking place. Hurrah!
So, a few things to say about what I’m looking forward to from April 25th to April 30th:
April 25: Penguin Day SF! It’s happening the day before NTC this year, not the day after. Gather with folks and spend an exciting day peer-sharing about free and open source software in nonprofit organizations. Any level of background in the topic is welcome, and everyone learns.
April 26-28: NTC. Another jam packed year full of great panels and expertise sharing. I’ll be involved in two panels this year. (And lots of conversations on the side.)
April 29-30: Hopefully, there will be a CiviCRM developer camp. Yay! I’ve been using CiviCRM for a year or so, and have begun to get involved in implementation. Looking forward to digging deeper in.
And email me if you want to have coffee, or lunch, or a side conversation in the Science Fair.
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.)
Some stuff from my inbox. (A lot of these are 2008 news, therefore, kinda old. But still interesting to me.)
Appirio releases their top 10 predictions for cloud computing in 2009. One of the more interesting ones is that “a major SaaS 1.0 company will fail.” I kind of wonder about some of the early nonprofit-focused SaaS offerings, and how long they might have to live, given the strength of Salesforce.com
Third Sector New England, a Boston-based nonprofit capacity-building organization launched a series of “FAQ” videos for nonprofits. Useful stuff.
This week was a bad week for online blogging services. First the blogging service JournalSpace, with hundreds of users, just, well, died, because they didn’t have a proper backup. Today, the hacking of the blogging service SoapBlox, which was used by many progressive political bloggers, such as Pam’s House Blend, became known, and it is currently unclear how many sites have survived, and what will happen to them.
These are two fairly small, fairly low-profile services (although SoapBlox is considered an extremely important part of the progressive blogosphere.) They hosted a small percentage of the blogs out there (in comparison to, say, TypePad or Blogger.) However, this is, of course, devastating to those who had their blogs there.
Lessons to learn:
Always have your own backup of your data/content
Remember when setting up a website or blog that if you use a service, the data is not in your hands, but in someone elses
