The Challenges & Rewards of Drupal/Salesforce Integration

CMS -> CRM - Drupal Integration

An important part of Achieve’s Bella Pictures project has been the integration of Ubercart/Drupal with Salesforce. Before Bella launched any Drupal sites, they used Salesforce.com to manage customers, contacts, and leads. They had invested a good deal of effort and money in customizing Salesforce to meet their organizational needs and, not surprisingly, wanted to continue using it.

So, in Bella's web site technology stack, Drupal had to perform customer-facing eCommerce tasks while also communicating effectively with Salesforce on the back end. The heart of the integration required Achieve to customize Drupal so it would automatically propagate orders and updates in Salesforce.

Background on Salesforce Integration

Salesforce/Drupal integrations are challenging for a number of reasons. One of the attractions of Salesforce is that it’s highly configurable—it can fit just about any organization’s workflow, nomenclature, and sales process. This flexibility comes at the price of a back-end that is consistent.

Add to this the fact that most Drupal installations are unique--because each employs a different set of modules and customizations--and it becomes apparent that each integration is different.

As a result, the contributed modules that assist in integrating Salesforce with Drupal are by no means plug and play solutions, and they generally serve as the starting point for Achieve's projects.

Why It’s Still a Good Idea

Despite these challenges, integrating Drupal with Salesforce has many advantages. Drupal, and its eCommerce module Ubercart, are open source, extensible, and can be modified to work with any Salesforce setup. Since Drupal can store and easily access just about anything you want it to, integration information (such as mappings and dependencies) can be housed within Drupal itself, as opposed to bringing in yet another resource and the accompanying access restriction headaches. Custom modules can then apply business logic to those mappings.

Furthermore, Salesforce provides an API that can supply dependency information about its own data (aka meta-data) for ingestion by Drupal. Also, the Salesforce API allows programmers to move Drupal data into Salesforce via SOAP.

Beyond the technical aspects, Salesforce.com is becoming an important player in customer relationship management. The cloud-hosted nature of the service provides organizations with superior flexibility and eliminates the need for dedicated hardware. Gartner found that Salesforce.com owned about 10% of the CRM market in 2008, which represented a huge increase over the prior year.

Because of their innovative approach to web 2.0 and their similar growth trajectories, Drupal and Salesforce will meet frequently in enterprise settings where technical managers want to move away from clunky proprietary systems with exorbitant license fees. Ensuring that these two technologies work well together will ultimately be in the best interest of both camps.

Bella-Specific Challenges

One of the difficulties specific to the Bella project is that a single Drupal(/Ubercart) node maps to multiple Salesforce objects. For example, one Ubercart product is six hours of wedding photography with digital negatives and a photo album. On the Salesforce side, those are three separate products.

The existing Drupal Salesforce module doesn't currently support one-to-many mapping. An enhancement request for this very feature is sitting in the queue on drupal.org, so one-to-many mapping may become part of the module at some point. But even if it does, the dependencies pose an even more significant problem. Not only might a single Drupal node force the creation of multiple Salesforce objects, those objects must be created in a specific order unique to the client’s Salesforce setup.

In Bella’s case, this meant that we needed to begin any order by creating an account and then retaining the auto-generated Salesforce account id. When we wrote the remaining objects (in the correct order), we'd need to input the account id as a foreign key.

Technical Overview

During the Achieve Discovery phase for Bella, we determined the Drupal functional requirements and examined Bella’s Salesforce.com data model and workflow. One of the notable customizations in Bella’s case was that the “opportunity” Salesforce object had taken on a central role in that system and contained many fields. In some organizations, the “account” or “contact” object takes on this role.

The Achieve team created specifications documents, taking care to determine the purpose of each field in Salesforce and its relationship to Drupal fields and objects.

Mapping & Coordination

Mapping the field types required building a custom module that allows an admin to configure and store one-to-many field maps in Drupal.

In the database, the maps looked like this:

Ubercart.product123 ->  Salesforce.account456
        Ubercart.product123 ->  Salesforce.lineitem789
        etc…

Note that Ubercart products may correspond to more than one item in Salesforce.

Also stored on the Drupal side are the object and field dependencies, which were accessed via the Salesforce API. With the maps and dependencies, we have the framework needed to run the syncing code.

Data-Syncing

To illustrate the syncing process, consider “checkout complete,” one of the triggering events. (There are two others, but they work similarly.) We hook into Drupal actions to run our own code:

hook_sf_account_export(&$account, $order) {
		$account.billing = $order.street . $order.city …;
        //etc. 
	}

After performing some initial error checking and parsing comma-separated data, this function determines whether the customer exists in Salesforce as an opportunity. Of course, we don’t have the Salesforce id, so we send the customer’s name and wedding date and, if that fails, the fiancée’s name. Depending on the response, we get the opportunity id, or create one. Then we proceed through the dependencies, creating objects and filling in fields in the order dictated by Salesforce

The function then creates XML envelopes with all the changes and deposits SOAP API calls in the queue. When the scheduled cron task runs, the envelopes are sent to Salesforce.

Bella sales representatives, already familiar with Salesforce, now have access to web-entered orders completed in Ubercart.

Customization and Integration

Because Achieve played a lead role in the Drupal development at Bella, the team was in prime position to identify the integration paths. The syncing of orders from Ubercart to Salesforce now works quiet effectively, and we’re continuing to add features and enhance the administrative ease-of-use.

There’s no way to get around needing to know a good deal about the organization-specific Drupal and Salesforce setups in order to integrate them. As a consequence, such integrations can be challenging but incredibly useful, if the flexibility of both systems is properly leveraged.

For many organizations, numerous possibilities exist to connect Salesforce with Drupal, even beyond the Ubercart eCommerce module. Uniting Drupal’s social publishing features with Salesforce’s ability to turn opportunities-into-leads-into-sales is one of the ways to convert community-building into business advantage.