Drupal-Salesforce Integration: A State of the Union, pt. 1

Salesforce is one of the most popular CRMs available today. Though initially created as a system for businesses to track sales leads and opportunities, it is now used by nonprofits for donor tracking, by venture capitalists for tracking potential investments, and by all types of organizations for project management and vertical-market applications.

Unsurprisingly, then, web development clients often request integration between Salesforce and Drupal. However, careful evaluation of their needs and budget is necessary, since there are several Drupal-Salesforce integration modules available, each with its advantages and drawbacks. No universal solution has yet been released.

Use Cases

Since Salesforce is a highly extensible system, the potential use cases for a Drupal-Salesforce integration are nearly limitless. In practice, however, most integrations fall into four categories: webform integration, user synchronization, e-mail campaign integration, and donation/e-commerce integration. These are the primary use cases that the current Drupal-Salesforce integration modules satisfy; most others, particularly those that involve the creation of multiple Salesforce records at once, would require custom development.

Use Case 1: Webform Integration

 webform to Salesforce Lead

Drupal’s Webform module serves as an excellent replacement for the Salesforce Web-to-Lead form.

Webform integrations are the simplest use case for Drupal-Salesforce integration. In these, the Drupal Webform module is used as a means to collect data from site visitors, creating one or more Salesforce records. Drupal’s Webform module serves as an excellent replacement for the Salesforce Web-to-Lead form, which is simply a cut-and-paste snippet of HTML and thus is both fragile and inflexible. It also can serve to collect data for Case, Contact, or Opportunity records, as well as any custom objects that may exist in Salesforce.

Use Case 2: User Synchronization

 User entity to Salesforce Lead or Contact

Various integration modules can sync Drupal users to Salesforce Leads or Contacts

User synchronizations are slightly more complex. In these, the creation of a Drupal user creates a Lead or Contact record in Salesforce, or updates an existing one. If user registration includes custom user or profile fields, these can also be included in the new record. It is unwise to store Drupal passwords in Salesforce, for security reasons, but it can be helpful to add the Drupal username to the record, particularly if the organization’s support staff are going to use Salesforce to respond to support calls about the website.

Use Case 3: E-mail Campaign Integration

 User subscription to Salesforce Lead or Contact + Campaign

With custom work, users' mailing list subscriptions can be synced to Salesforce Campaigns

E-mail campaign integration typically builds off user synchronization, by allowing users to subscribe to mailing lists on the Drupal site, which are then managed as Campaigns in Salesforce. The actual mailings can be sent either by Salesforce directly, or by one of its add-on apps such as VerticalResponse. For this integration to work, the users need to exist in Salesforce already as Leads or Contacts so that they can be added as Campaign Members to the proper Campaign.

Donation/e-commerce integration, likewise, builds off user synchronization, but is more complex, since multiple objects need to be created in Salesforce in order to properly track a financial transaction. At the least, a Contact, Account, and Opportunity record need to be created.

Use Case 4: Donation/E-Commerce Integration

 Orders in Drupal to Salesforce Opportunity

E-commerce integrations to Salesforce are complex, involving multiple objects

The Account record represents the organization making the purchase (which can have the same name as the Contact, in the case of purchases made by individuals). The Opportunity record represents the purchase itself, and includes a Close Date (date of purchase), Stage (i.e., completed), and Amount. It can also be linked to a Line Item record, which indicates what product was purchased.

Custom integrations

Custom integrations, finally, could involve any number of Salesforce objects. Possible types would include integration of an event registration system with Salesforce, contract management in Salesforce, using Salesforce to manage access control for nodes, integrating an issue tracker with Salesforce, or using a combination of Drupal and Salesforce for project management. If the integration requires Drupal objects besides users and nodes to be source data in Drupal 6, or if it requires multiple objects to be sent at once in Drupal 7, then custom development will be necessary.

Available Drupal-Salesforce Modules

Though some Drupal-Salesforce integration modules are specific to one of the use cases described above, many use cases can be satisfied by two possible approaches: either the Salesforce Suite (http://drupal.org/project/salesforce) and its dependent modules, or else the Springboard install profile (http://drupal.org/project/springb...), which contains modules that satisfy the first four use cases described above.

comparison of modules for modules for Salesforce integration

A comparison of the available modules for Salesforce integration.

Salesforce Suite and Springboard

The Salesforce Suite and Springboard currently have opposing design philosophies, which make them suited for different projects. The Salesforce Suite was designed, like many Drupal modules, as a loosely-coupled, generic integration framework which developers could build upon to satisfy a particular use case. This gives it a great deal of flexibility, but at the cost of usability: non-developers are not likely to be able to implement it successfully without assistance. By contrast, Springboard was designed initially as an install profile, not just a set of modules, and so will satisfy a particular set of Salesforce integration use cases out of the box. Springboard was designed specifically for nonprofits, though, so it may not be a good solution for corporate clients wishing to integrate with Salesforce. More significantly, it is currently only available for Drupal 6, so may not be a viable option until it has been upgraded.

The Salesforce Suite supports user synchronization out of the box, via the Salesforce User module in Drupal 6 and Salesforce Entity in Drupal 7. It used to support webform integration, via the dependent module Salesforce Webform (http://drupal.org/project/sf_webform), but the fate of that module is still uncertain (see http://drupal.org/node/1101632). In the interim, webform integration is provided by a sandbox project for Drupal 6 (http://drupal.org/sandbox/evandon...); there is no current equivalent for Drupal 7. E-mail campaign integration would currently require custom development, at least to provide a usable integration. E-commerce integration is provided by the Ubercart/Salesforce Integration module in Drupal 6 (http://drupal.org/project/uc_sale...); there is no current equivalent for Drupal 7 and the Commerce module.

The main strength of the Salesforce Suite, however, is that it provides a robust collection of hooks that enable it to be extended for additional use cases without the need to hack its code or use the Salesforce web service APIs directly. Documentation is available on Drupal.org (http://drupal.org/node/1098904), and code examples are provided in the module itself (http://drupalcode.org/project/sal...). These hooks have made various special use cases possible, such as the Feeds integration provided by the Salesforce Feeds module (http://drupal.org/project/salesfo...).

On the other hand, Springboard’s user-centric approach makes it well-suited to a range of use cases out of the box. It offers webform integration via the SF Webform Integration module, user synchronization via the SF User Integration module, and donation integration via Fundraiser and dependent modules. It doesn’t appear to offer a dedicated module for e-mail campaign integration. It does, however, provide a unified administrative interface, called Springboard, through which regular site users can create webforms and donation forms that integrate with Salesforce. This is a dramatic contrast to the mapping interface used by the Salesforce Suite and dependent modules, which is quite powerful, but means that it would likely require a developer to configure new integration points between Salesforce and Drupal.

Salesforce Webform Data Integration module and Salesforce Web-to-Lead Webform Data Integration module

Apart from the Salesforce Suite and Springboard, there are two dedicated solutions for webform integration with Salesforce. These are the Salesforce Webform Data Integration module (http://drupal.org/project/salesfo...), and the Salesforce Web-to-Lead Webform Data Integration module (http://drupal.org/project/sfweb2l...). Both of these have versions available for Drupal 6 and 7, and have more usable interfaces than the Salesforce Suite, since the mapping is done on the Webform’s configuration screen, rather than in a separate mapping interface.

Webform Data Integration module screenshot

Mapping fields in the Webform Data Integration module is done in the Webform configuration interface

However, the Salesforce Webform Data Integration module is more flexible, since it can create any object available in Salesforce, whereas Salesforce Web-to-Lead Webform Data Integration posts the data to a web-to-lead form in the background, and thus can only create Leads. If the client’s Salesforce integration needs are limited to webform integration, either of these could be the best option, but if more integration is needed later, it might be best to start with the Salesforce Suite as a foundation, since it provides a common core of Salesforce authentication and field mapping code that can be used by any number of different integrations.


Each of the current module-based solutions for Salesforce integration has advantages and drawbacks. The Salesforce Suite offers a broad range of functionality, but its developer-centric approach means additional work is needed to put together the pieces required for a given project. Some of the main use cases for Salesforce integration don’t have a stable implementation yet which relies on the Suite as base. Thus, it is best for projects where developers are available who have experience in Drupal, web services, and ideally Salesforce, and where the client’s needs are unique. Springboard offers more targeted functionality, and thus can be implemented more quickly, but is designed specifically for nonprofits, and is currently available only for Drupal 6. Thus, it is best suited to donor-focused nonprofit sites, which are a mix of static pages and webforms. Until it is clear how it will be upgradeable to Drupal 7, it would be a risk to start a more complex site development project with it. Finally, the modules that provide webform integration only may suit basic use cases (such as replacing Salesforce’s own Web-to-Lead form functionality), but may prove limiting as site development progresses and clients request a tighter integration between Drupal and Salesforce.

Though solutions for Drupal-Salesforce integration exist, as described here, none offer all the features one might desire, with usability comparable to that of Salesforce itself. Some clients' needs may best be served by the integration systems that can be used outside of Drupal to pull data into Salesforce. These will be described in the next blog post in this series.

We want to work with you!