Posts tagged as:

integration

Drupal and Salesforce

December 31, 2009

It’s taken me a while to write this blog post, mostly because I have been working hard at various things (like building a business and building new websites.) This is the last installment in my CRM/CMS integration series, that started almost a year ago (wow!) And I’m skipping Joomla/Salesforce Integration because there isn’t any publicly available documentation or code about the integration that PICnet did with Joomla and Salesforce, called J!Salesforce.  [update: see Ryan's comment below.]

So what is the state of Drupal/Salesforce Integration? It’s not as mature as the Plone/Salesforce integration, for sure, but it is coming along nicely. There are several contributed modules:

  • salesforce – main module, with API, node, and user integration possibilities. This module provides the basic salesforce API connection (via SOAP), and includes field mapping, and basic import/export
  • sf_webform – Makes integration with webforms in Drupal fairly easy. Web-to-lead is quite nice and flexible with this module.
  • uc_salesforce – Provides integration with ubercart orders
  • parser-salesforce – Integration with FeedAPI – pulling data from salesforce into drupal nodes via FeedAPI  (I hope to start maintaining this module)
  • sf_import – Import Salesforce objects into Drupal nodes (will be folded into the main salesforce module)

All of these modules are in alpha or beta, although I know for a fact that some of them (or versions of them) are working in production sites. There are a fair number of bugs that need to be fixed before there is a stable release. There are a bunch of outstanding issues that need a lot of work (like caching, for instance). There are two other modules that are related, but don’t use the main salesforce api module – one for ubercart, and one for web-to-lead (called salesforcewebform). That module has a stable release, but only provides the ability to integrate between Webforms and leads, not other objects.

Right now, the salesforce module allows for integration of contact, lead and campaign objects only. so that’s another big area that could use some work.

There is a good screencast done by one of the folks (Jeff Miccolis from Development Seed) who has worked a lot on this project.

I’d say that in a year, we’ll have a good solid module release, providing lots of features for integration between Drupal and Salesforce.com.

Tagged as: , , , , ,

{ 4 comments }

CRM & CMS integration: Web pages and forms

April 15, 2009

Third to last in my series on CMS and CRM integration (next up, Joomla and Salesforce, followed by Drupal and Salesforce) is using web forms.

I wanted to talk about this because it is arguably the most common form of “integration” between CRM and CMS that’s out there (besides the manual kind). You’ve got a CMS, and you’ve got a CRM somewhere else, and you need some way for data from users to make it to your CRM. Of course, it’s not really integration – there is no sharing of data between the CMS and the CRM in any useful way. But webforms can really help you get things done. Here are some examples of things I’ve done and seen done:

  • A custom donation page that’s sitting on a service like Network for Good that is linked from the website, or framed within it
  • The HTML for a “Web to Lead” form from Salesforce.com pasted into a CMS page
  • The HTML for a event registration form or donation form that goes to a hosted service

In the first option, the form isn’t hosted at all on your site. In this option you have the least control over look and feel – the vendor controls the look and the behavior. An example of this I’ve run into is when an organization uses Blackbaud’s Raiser’s Edge, and wants to have online donations via NetSolutions, their older (and much cheaper) “integration” tool. They provide a page, which hooks directly into the users RE installation. But you can’t customize the page in any useful way, so if you’ve just designed a brand-spanking new site, this page is gonna look like crap. (Luckily, at least Network For Good’s donation pages look snappy and nice, but are going to look a lot different than your website.)

The other options are much better for look and feel – you can take the HTML, and, in most instances, style it to look like your site. You can even sometimes include Javascript for validation or other functionality. But this is still strictly one-way communication – the form data goes directly to the service (and does not pass go.) You don’t get any of it.

This is a great start to integration, if your budget doesn’t allow for true, deep, two-way integration between CRM and CMS. And it’s a great way to get your feet wet in thinking about what you might want to do with CRM and CMS. And, in some instances, depending on both CRM and CMS, it might be your only option.

Tagged as: , , ,

{ 2 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 }