Hello, my client is using Salesforce "nonprofitforce," and we're now implementing Drupal 5.10 for their CMS. We'd like to integrate according to the following specs, but I was hoping for feedback, so we could help this project as well as ourselves. After a QA/security audit, we could release the code, either as a quality patch for Victor, an add-on module to the current SF module, or even a separate module. Apologies for any redundancies: I haven't dug into the current modules; I've just been reading the forums.
1) I was advised that bi-directional synching is not ideal, but right now it seems too complex to rework Drupal as a "thin" interface with Salesforce handling *all* user data persistence
2) We mainly want Drupal to "feed" Salesforce data. The main problem at this point is dupes. We have a "dupe" tool within Salesforce so staff members can manually handle any "dupe" candidates
a)Drupal would check the SF contacts for a Drupal ID field. If null, it attempts a first name/last name/email match. If a match is found, it would enter and/or update it's user data/preferences. It would also fill the Salesforce Drupal Id field with the user's uid.
b)If there is no SF match at all, it would create a new record. It might toggle a "possible dupe" field when this user came close to matching first name/last name/email. For the SF username, it could maybe use username1, username2, etc.
c)If there is a match (from the key/ID field, or first name/last name/email), then it would just update all fields
3) Salesforce-wise, I don't think we need SF to create new Drupal users (plus we'd want to use email confirmation, and lots of people would be surprised to suddenly get the notice).
a)Whenever a SF contact record is updated (or periodically), if a Drupal ID field exists, it would update certain corresponding fields within Drupal. This sounds a bit messy, but we need to have some data overlap with Drupal and SF. At some point, perhaps we could even further the eojbrave "Salesforce Accounts in Drupal" (Salesforce Objects as Nodes) module.
Since we'll budget for testing, I am open to "wishlists." I'll soon be releasing this as an RFP for the project and/or testing/security.
Comments
Comment #1
aaronbauman#702614: 5.x branch is no longer relevant. Let's drop it.