Salesforce/Drupal Integration?

I’ve been investigating the possibilty of using as a CRM backend to a Drupal CMS website. Drupal is one of the more mature, community-centric platforms available and has a strong ecosystem of developers. Salesforce has an equally strong network and also highly extensible through its open API.

Currently, the only Salesforce/Drupal module I’ve found doesn’t quite meet our needs. However, I was exploring the AppExchange and found a free product called Apatar. This Windows-based tool provides a very easy visual interface for creating ETL (Execute Transform Load) connections between Salesforce and other databases; Oracle, SQL, MySQL, etc . This is a very techno-speak way to say it can create a bridge for data between two apps.

Since Apatar supports Salesforce and MySQL, the db behind Drupal, perhaps an integration need only exist in the background data transfer between the exisiting databases. Meaning no coding or module creation in Drupal or Salesforce. This would also means less money speant on development.

Given that I don’t know Drupal’s database schema very well, I went searching for documentation or even an ERD (Entity Relationship Diagram). Zilch on Drupal’s site, but a very enterprising fellow used another open source tool called SchemaSpy to create an ERD for the 5.0.21 version of Drupal. (Note to self: write an open source application.)

Armed with this information and ETL tool, I have what I need to see how viable an idea this could be. The first step is to define the scope of this "integration". At first blush, I think it is possible to synchronize the name, email, and password feilds between SFDC Contacts and the Users table in Drupal. Will it work? Wait and see. 

Salesforce for Non-profits

Looking over my posts, I was surprised at the dearth of Salesforce related articles. Especially given how often I champion it offline.

About two years ago, my first task as the first IT director at my small non-profit org was to identify, evaluate and recommend a contact management system. After reviewing the standard players in the not-for-profit sector (Kintera, GetActive, Convio, Raiser’s Edge), I expanded my search to commercial products. Honestly, I think too many non-profits overestimate the differences between them and their for-profit counterparts. Products and vendors targeting this sector often play to that conceit. Ultimately, non-profits end up with boutique products that are not nearly as robust or battle-tested as those used in the for-profit sectors. With that mindset, I was more than open to the suggestion Rem Hoffman from Exponent Partners made about checking out (SFDC).

At the time, SFDC was not nearly as well know in the social sector. That has since changed due in no small part to the great work by the Salesforce Foundation. The first thing that struck me about SFDC and its foundation was the parity of the relationship between the two. CEO Mark Benioff is very involved in the foundation and makes it very obvious that this is not just some half-hearted effort towards corporate responsibility. 

Through the foundation, registered non-profits can receive donated licenses for Salesforce Enterprise Edition. More to their credit, SFDC has prompted its extensive ecosystem of partners to do the same. We’ve received generous donations and discounts from;

Because Salesforce has an open API, it integrates well with third-party products and is highly extensible  through custom porgramming.  This has allowed us to build a best-of-breed integrated system that connects information from all of our systems including our website. Donations have allowed us to achieve this at a reduced expense. What started as a quest for a CRM system has quickly grown into a comprehensive ERP system. Nearly everything we do is based off the SFDC platform.

I recommend that non-profits consider Don’t let the name put you off.

Configuring WikiMedia for an Active Directory based intranet – Part 3

A while ago, I wrote a post about setting up MediaWiki as an intranet for my non-profit organization. Not wanting to burden people with yet another set of login credentials, I set the wiki to authenticate off of our Active Directory server using the LDAPauthentication extension. At the time (version 1.0 f), the documentation for Windows and AD was spotty and I was glad to add the results of my trials and errors. One thing I was never able to do was have the user prefs (full name and email) pulled from the AD to the wiki user profile.

Since then, the extension has been updated to 1.1d and that feature is more readily available. There are new instructions for configuring an AD server on the Configurations Examples page. To my original code  in LocalSettings.php;

## attempt at authenticating off of  Active Directory at
require_once( ‘LdapAuthentication.php’ );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "testAD" );
$wgLDAPServerNames = array( "testAD"=>""  );
$wgLDAPUseSSL = true;
$wgLDAPUseLocal = false;
$wgLDAPAddLDAPUsers = false;
$wgLDAPUpdateLDAP = false;
$wgLDAPMailPassword = false;
$wgLDAPRetrievePrefs = true;
$wgMinimalPasswordLength = 1;

I added the following;

$wgLDAPSearchStrings = array( "testAD"=>"testAD\\USER-NAME"  );
$wgLDAPEncryptionType = array( "testAD"=>"ssl" );
$wgLDAPSearchAttributes = array(

$wgLDAPBaseDNs = array(

Success! Now the full name and email address appear in Special:Preferences after a user successfully logs in. Finally I can have closure.

Or not. Apparently this works for domain users who have already logged onto the wiki prior to the update, but not those created afterwards. Those users get a Internal Error page with a password-change-forbidden message. Luckily, some intrepid techies had found a solution and posted it (albeit cryptically) on the LDAPAuthentication discussion page. If you have version 1.1d you only need to make changes to the SpecialUserLogin.php in the Includes directory.

Since I don’t have access to the Patch util in Windows, I had to update the file by hand.  To do that, make a backup first. Open SpecialUserLogin.php and find the function initUser (lines 309 to 323). Replace the entire function with the the following code.

function initUser( $u ) {
        global $wgAuth;


               if ( $wgAuth->allowPasswordChange() ) {
                       $u->setPassword( $this->mPassword );

        $u->setEmail( $this->mEmail );
        $u->setRealName( $this->mRealName );

        $wgAuth->initUser( $u );

        $u->setOption( ‘rememberpassword’, $this->mRemember ? 1 : 0 );

        return $u;

Success? So far. I created a new domain account and then used it to log on to the intranet. No Internal Error, so I assume everything is Kosher now. I’ll keep you posted.