From the category archives:

CMS

CRM&CMS Integration: Blackbaud Raiser’s Edge and NetCommunity

February 13, 2009

What? She’s talking about Blackbaud?

Yes, it might be surprising, but I got a friendly email from fellow NTEN Board Member Steve McLaughlin, who also happens to be head of all things internet (more formally, Director, Internet Solutions) at Blackbaud. He gave me a demo and overview of their NetCommunity tool, which has been around for a while, and I figured it deserved a blog entry. It is, in fact, a great example of integration of a CMS and a CRM. Originally, I wasn’t going to cover the one vendor solutions, like this because, I believed (and, honestly, I still do) that you’re not going to get as powerful a CMS as you can as the best-in-breed CMS tools. However, it is true that Raiser’s Edge, the CRM/DMS tool that this integrates with, is inarguably one of the most important tools out there. Some call it the gold-standard. For many other CRM/DMS vendors, it’s the red spot at the center of the dartboard in their office.

The demo was pretty cool. But you know me, I fall for shiny, especially when it comes to data. The integration between the web front end and the RE back end is bi-directional and sweet. There were a lot of things you could do, including accept donations, track personal donation pages, and the like. and a lot of different ways to track what your donors and constituents did, both online and off, and have those show up in really interesting ways. It is, in many ways, the kind of CRM/CMS integration that lots of organizations want and need. Organizations can get this package in three different ways: On premises – installed inside the firewall, hosted, or SaaS. Their SaaS offering is called “NC Grow”, which provides sets of fairly simple CMS templates to start with, designed for organizations that, in their words, “are ready to reap the benefits of richer online marketing and communications, but may not have the resources or expertise in place to make such a website come to life”

The big kicker, pretty much as always with Blackbaud, is the price tag. There is a $10K license fee that you have to pay if you use the On premise or hosted versions. Expect a $35-45K price tag for development and integration. Their SaaS offering, NC Grow has a $20K/year price tag. This all is, of course, above and beyond the megabucks you’re already paying for Rasier’s Edge.

I didn’t get a very close look at the CMS (I’m wishing in retrospect that I had), but the little bit I did see of it suggested to me that it was somewhat more limited than CMS systems such as Drupal or Plone. Even if, perchance, it’s not, you still don’t get the vibrant community of developers making cool modules and add-ons to do just about anything you can imagine – you’ll have to either wait for Blackbaud to do it, or, perhaps (I’m not even sure if this is possible, but correct me if I’m wrong in comments) have someone custom develop special custom features for you. And, you’ll have an automatic $10K price tag tacked on that you won’t pay with the open source tools. I have a hard time believing that that translates to $10K worth of feature value (one could argue it’s $10K worth of integration value, though, but I’m not sure about that.)

Bottom line: If you are an organization which has Raiser’s Edge, and is committed to keeping it, and you want to do sophisticated integration between it and a web front end, then NetCommunity is probably your best solution. But before you jump in, make sure that the CMS is going to have the sophistication and power you need. And know that because RE doesn’t have open APIs, you are unlikely to be able to create the kind of sophisticated integrations with a different CMS that NetCommunity provides with RE.

But, if you are not a RE user, or are considering migrating off of RE, I don’t think that the combination of RE and NC is especially cost-effective. You can get this level of integration with Drupal/CiviCRM for sure, and likely Plone/Salesforce, and Drupal/Salesforce (with a bit more work.) More on those later.

Tagged as: , , , ,

{ 18 comments }

CiviCRM and Drupal (& Joomla)

January 26, 2009

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.

Tagged as: , , , ,

{ 3 comments }

Integration of CMS and CRM – Preamble

January 26, 2009

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: , , ,

{ 3 comments }

Integration of CRM and CMS

January 14, 2009

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: , , ,

{ 18 comments }

Drupal and Postgresql

November 22, 2008

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.

{ 0 comments }

Next Entries →