Closed (won't fix)
Project:
Salesforce Suite
Version:
7.x-3.x-dev
Component:
salesforce.module
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
5 Aug 2015 at 18:09 UTC
Updated:
21 Feb 2026 at 19:06 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
TravisJohnston commentedComment #3
TravisJohnston commentedThis is still really needed. Most of the Commerce and Commerce Registration workflows I have been able to combine and do a 1 to 1 mapping, but how are you supposed to handle Payments when there are different Types of payments that people can make?
These are separated out into Entity Bundles of the Payment Transaction Entity.. So I can only choose one payment bundle to send to Salesforce?! Or are bundles an exception and it's only the Entity Type that is 1-1?
Comment #4
TravisJohnston commentedTo work around the Payment issue, I have created a custom module to add new payment columns to the Commerce Order table and assign the payment information to that, so they are then accessible within the single order entity. I don't want to consider this closed though as this is a big picture issue and is needed for those that should not need to dive into a custom module or stitching together multiple things into one to make it work for larger scope integrations.
Comment #5
sergei_brill commentedI'm interested in one-to-many mapping feature. One of usage case for me is mapping one SF object to node type and commerce product since SF object stores images, description, name, price, etc. Also mapping of 2 SF objects to 1 drupal entity would be nice. On SF I have a kind of templates and final objects which references to a template. But in drupal I don't need 2 bundles, I only need to display combined data from both SF objects.
Table salesforce_mapping_object have this configs for unique keys
What if we change it to
and update functions which loads data from the table. Does it make sense? Will it bring new problems?
I really need these features and I'm ready to work on patch for the module.
Comment #6
sergei_brill commentedI started to work on one-to-many mappings in both directions. First patch is for current stable version 7.x-3.1. It was tested and it works for me at least with simple cases when 2 entities mapped to 1 SF record and vice versa. Second patch is for current dev version of the module.
Comment #7
0livier commentedHi,
In your case we have two content type for one salesforce object. Whe push content type 1 to account object and we pull account object to content type 2. But function salesforce_mapping_object_load_by_sfid() only return one entity, and salesforce_id is unique key in database.
So this patch add entity bundle in salesforce_mapping_object to allow this.
Comment #8
othmen commentedFix issues with path to changed files.
Comment #9
TravisJohnston commentedI haven't updated this for awhile but I no longer use the GUI provided by this module. Instead, I use a couple of the methods it provides in a custom module of mine which controls all of the mapping. What's nice about doing it in code is I can also do a lot more validation checks before I do anything. So for Contacts, I can check to see if they exists by looking at things like First Name, Last Name, and Email together before determining if they are new or existing.
What's also nice is the ability to break up a Drupal entity into different objects (Many to Many) in Salesforce and visa versa by using separate API calls for different fields. For instance the same entity in Drupal contains Contact Information for the person and their Company Address. So in code I can check for the person and and look for an existing Account that matches the Company Address.
So much nicer yet it does get a little daunting after awhile... I wrote a little about it here: http://blog.collaborative.org/technology/2016/03/customize-syncing-between-drupal-and-salesforce-part-1/
Comment #10
aaronbaumanI think this change makes sense, including changing the mapping object schema to include entity bundle.
But I don't think we should change the signature of salesforce_mapping_object_load_by_sfid() in a way that's not backwards compatible. Contrib modules may rely on this.
The arg order needs to be preserved (ie. make $bundle argument last), and an empty default supplied to preserve existing behavior.
Travis, those blog posts are great!
Comment #11
mèche commentedJust check if drupal_bundle is set, to avoid notices
Comment #12
markusa commentedThis would be a great feature to be in the official release of this module.
I'm working on a new Salesforce integration, and it would be awesome to be able to push sync one Drupal entity type to two different Salesforce objects, programmatically deciding when a entity should be synced to which SF object..
I'm going to try to see if these patches are applicable to 7.x-3.3-beta3
If anyone here has tried this on v3.3-beta3 and wants to share, that would be awesome! Thanks!
Comment #13
aaronbauman7.x is no longer supported