Please Login with your Salesforce ID to post, promote or comment.
Salesforce IdeaExchange
FAQs | Terms of Use8282 Ideas; Promoted 177420 Times; 17086 Comments.
- Suggest a New Product Concept
- Promote Ideas That You Want to See Developed
- Discuss With Product Managers and Other Users
- See What We Are Planning To Deliver
Many to Many Relationships w/ Linking Object
Problem: If you would like to create a “Many to Many” relationship between objects you must create a linking object in the middle. The linking object can contain more then the ID fields, but primarily contains the IDs of the objects that it is linking. This poses a HUGE problem with reports, related lists, etc, even with report types. There is no way to show or report on the Many to Many relationships. You can only report on one of the primary objects and the linking object. Without de-normalizing the data and saving fields to the linking object reports are very limited.
One Current Solution: To overcome this we have had to de-normalize the data model. We take fields from both primary objects and replicate them on the linking object creating a composite object. This has to be done with APEX, AJAX or some code external to Salesforce. It is very cumbersome to code this type of solution and challenging to ensure data integrity when one of the primary objects data changes. Also, if future reporting requirements change we have to code, not configure, a solution.
One Proposed solution: Create a field type called link or “Many to Many”. Under the covers Salesforce could create the linking object storing the IDs from the two primary objects. Then Salesforce could expose this in reports, related lists, etc. Since Salesforce created the linking object the system would have more control over the data model and create the composite view.
Thanks,
Todd Bursey
Appirio
|
Tom_Tobin 12/05/07 |
Why not use Custom Report Types? http://blogs.salesforce.com/analytics/2007/10/hiding-or-polit.html |
|
Scott_Jorgensen 12/06/07 |
If you define a Custom Report Type you can report across your many-to-many relationships. Also, if one of the relationships is a Master Detail and another is a Lookup then you'll get a standard report automatically the spans the many-to-many relationship...no need to make a Custom Report Type. |
|
Tom_Tobin 12/06/07 |
I don't understand what you want to list in a listview? Wouldn't it be better if listviews and related lists could be based off a CRT and you could go lookup any field you wanted? |
|
toddb 12/06/07 |
I've uploaded a picture to help explain the problem. https://na3.salesforce.com/servlet/servlet.FileDownload?file=01550000000IIVu< report types will work, that would be great. I'm not sure if they will. report types work on a tree that has multiple parent->child->child relationships. With report types you can not go from parent to child then back up the tree to another parent....Correct??? Also, I was talking with another consultant on our team and he mentioned it would be great to have "Roll Down Fields" for any relationship (not just master-detail). This would allow the linking of mutiple objects and allow fields/data to be present in the linking object forming the composite view. This would also allow other fields to be added to linking object making it more generic and useful. |
|
toddb 12/06/07 |
The link above is bad. Try this https://na3.salesforce.com/servlet/servlet.ImageServer?id=01550000000IIVu&oid... |
|
Tom_Tobin 12/06/07 |
you can go back up. In the "Edit Layout" page, choose the object you want to go back up from, and click "Add fields available via lookup". Or read the 2nd half of the blog post, which says the same thing. |
|
curth 12/10/07 |
I support the idea that Salesforce.com needs to make it easier to create many to many relationships and include those relationships in reports. In addition, Custom Reports only works if you are reporting on object, parent object, grandparent object, etc. It is not well suited for reporting on grandparent, parent, and 2 grandchildren objects. |
|
Tom_Tobin 12/12/07 |
Custom Report Types will work for 4 children of the primary object. But often, you can choose the primary object. From the primary object, you can follow lookup relationships up to 4 steps away - looking up the great-great-grandparent. |
|
AlexCRMmanager 12/18/07 |
I agree with Toddb - the way we have to implement Many-Many relationships is Salesforce.com often ends up being rather ugly and un-user-friendly for the end user. Salesforce.com needs to make the process of creating a Many-Many relationship more streamlined for the developer, and simpler for the end user. We need to be able to create things like Contact Roles without have to do a lot of custom code to make the interface nicer and easier for the end user. |
|
xactandy 12/19/07 |
A bigger issues is deletion of dependent relationships. So if you have a many to many between two objects, and you delete one of the objects, then the dependent relationship should be deleted as well. The only way to do this is Apex or an S-Control. |
|
Tom_Tobin 12/19/07 |
The junction objects can be a detail of one side, which is often enough - a test drive object linking a car to a customer shouldn't go away when the car is sold... but might go away if the customer is deleted. The best option right now is to use Apex or SControls to create the junction object and the item on the far side from one form - allowing the user to not have to worry about the complexity, and build a CRT to let them report over the junction. Having M:M would not work well in many situations, and would complexity the security and related-list and join management a lot, and would only be really useful for when there is no information on the join itself. If there is information to keep in fields on the join, then you need an object in the middle anyway. |
|
EricB Mar 31 |
Changed status to Coming in Summer 08. |
|
hpPMO Apr 15 |
Is this same as : http://ideas.salesforce.com/article/show/10079268/CrossObject_Formula_Fields_...? |
|
ToddJanzen Apr 21 |
I think this would solve my idea as well: http://ideas.salesforce.com/article/show/26498/Contact_to_Contact_Relationships |
|
rich_r. Apr 24 |
So does this mean that when creating a contact to contact relationship, I will no longer have to use an s-control to display the relationships on the contact layout; or alternatively use two related lists on the object. Please advise so I don't spend too much time developing these s controls. Thanks. |
|
kjoseph Jun 19 |
Changed status to Delivered. |
- zabby_fazel
- franklin
- narasimha_rao
- jnugent
- heyjenromano
- AnnaKovtoun
- tlnguyen
- iwyatt
- 04/6/2007_4:34
- alexy1967
- big.t
- eterps
- ChrisMcL
- KevinMc
- vipul_pahwa
- paulMcGurn
- joyce_lee
- robertokaiser
- cpierre
- jason_macdonald
- mojeebahmed
- mwyatt
- vinckey1
- Christoph_K.
- codybraxton
- vorno
- jasonfluid
- phonenomena
- arronj
- PaulN
- crmzepher01222008
- andrew@asa
- kleiserson10132007
- chopair
- klineberry
- Lacertosus
- Chelle
- EM
- 03/1/2007_19:32
- sgking
- ryan_hallman
- Jefe55
- justedel
- Marie_Admin
- Robbert
- ken.struthers@multiplex.biz
- dmsx2
- roblawmaxrecruitment
- morningstar
- mfriend
- Maryann
- cribis
- RentokilAlec
- 01/6/2008_5:21
- rsunderland_gtsi
- hal1975
- joon_brown
- CSchares
- TimMadigan
- CQuek
- ebarfield
- pkim04152008
- Westwood
- hagengm
- faquino101
- adrians
- Francesco23
- cerijones
- craskulinecz
- ToddJanzen
- ottodahl
- timrnichols
- markbc2
- paul_underbrink
- bliss
- joseph_ferraro
- analog
- CM@affy
- natek
- mshinn
- KFret
- TrevorIDP
- Scott_Jorgensen
- sara_chieco
- srlambert
- mark2008
- jcoppedge
- Ben-Generate
- dfg713
- sfdc4me
- hpPMO
- capnkaos
- cases02072008
- dmrs22
- pbueno11272007
- EricB
- jtasaki1
- Marc_Baizman
- nicolas.orzabal@averydennison.com
- seand