I’m assuming it’s possible to have a many-to-many relationship using two lookup relationships? In the example you had, if we didn’t care about roll up summaries and security, then could we also use lookup relationships to establish the many-to-many?
Correct you can have lots of m2m’s using lookup relationships – obviously the relationship will behave differently (no cascade deletion, security, etc.)
from this article “ttps://help.salesforce.com/HTViewHelpDoc?id=relationships_manytomany.htm&language=en_US
i understand that a many-to-many relationship must be constructed by two master detail relationships (not a look up relation ship)
from the article: “You can use master-detail relationships to model many-to-many relationships between any two objects”.
am i right ?
Many to many relationships can be created through master/detail or lookup relationships (or one of each) – the way the relationship functions (cascade deletion, security, etc.) will defer depending on which field types you use.
That makes me think how can we link 1 contact to 2 accounts pls provide in step by step guide
In that case you should use contact roles- the data model already accounts for this
Great example, took a while to figure it out. Tried with my own custom example to get the crux of it.
John, I’m not clear on why you needed to create a Cross-Object Formula to add Seats to the Course Offering page. You were able to add “Name of Course” by selecting it from a list. Why can’t you just add Seats in the same/similar way?
I figured it out. Thx.
Is a many to many relationship defined as 2 master-details on the junction object only? I found an example where campaign member can be a junction object between contact and campaign in a many to many relationship but it contains lookup to those. Can 2 lookups define a many to many relationship too?
Yes, absolutely – can be either master-detail or lookup (or a combination of the two).
Thanks very much!
Great topic…. u just go too fast for me. I will have to stop and start many times to duplicate the scenario at my end.
Lol, same here Munira! 😛
Here is a use case question:
I have custom object A that is related to both accounts and opportunities.
1. When an account is removed I want to remove all custom object A records, as I dont need them.
2. I want to display the related list custom object A on the page layout for both (accounts/opportunities)
3. if an opportunity is deleted, i do NOT want to remove any rows for custom object A
4. From account layout be able to create new custom object A records.
5. from the opportunities layout NOT be able to create custom object A records.
Create a custom field on custom object A master-detail (account).
Create a custom field on custom object A master-detail(opportunities).
Customize account and opportunity layouts to display relate list custom object A.
how to prevent a deleted opportunity from purging custom object A records.
Create a custom field on custom object A master-detail(opportunities). <-- Make this a lookup relationship.
if an opportunity is deleted, i do NOT want to remove any rows for custom object A <-- You want a lookup, not a master detail
from the opportunities layout NOT be able to create custom object A records. <<- remove the "new" button from the related list on the opportunity for the A object
update the field type from master detail to lookup relationship for opportunities
In the ‘Considerations for Relationships’ reading from salesforce, these two sentences seem to contradict: ” For example, if the sharing setting on both parents is Read/Write, then the user must have Read/Write access to both parents in order to have Read/Write access to the junction object. If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object.”
Why if the sharing setting is read-only on both masters, would the access to the junction object be Read-write?
Where did you see this text? “If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object”
If you have read to both parent objects, you should not inherit read/write to the child. However, it does depend both on object-level security and record-level security, so there may be some additional context to the statement.
I found it at https://help.salesforce.com/HTViewHelpDoc?id=relationships_considerations.htm&language=en_US >> Many to Many Relationships >> paragraph 2 >> sentence 3. No other context given. Quite confusing.
Ah I get it.
That is confusing – I would have thought it would only carry over read only which is perhaps why that warning is in the text.
The text that you highlighted- If, on the other hand, the sharing setting on both masters is Read-Only, a user with Read-Only rights on the master records would have Read/Write access to the junction object
Or you could have two classes in the same room but at different times ?
Yes you could
Should the 4 course offering records not be –
2014 math101 classroom a
2014 english101 classroom b
2015 math101 classroom “B” (instead of A)
2015 english101 classroom “A” ( instead of B)
If it is not why?
Yes it would thanks Matt, typo on my part.
Hi – I’m curious to know your reasons for making the relationship between course offering and course / classroom as both being one to many – I would think that unless the course was subscribed over the maximum occupancy of a single room then there would be one classroom and one course per course offering? Am I missing something?
MATH101 is offered in classroom A – 25 students
ENGLISH101 is offered in classroom B – 30 students
A max occupancy 25
B max occupancy 40
MATH101 is offered in classroom B – 40 students
ENGLISH101 is offered in classroom A – 25 students
MATH101 is a course
ENGLISH101 is a course
Classroom A is a classroom
Classroom B is a classroom
How would you offer the same course more than once, or use the same classroom more than once?
The way we can do that is using a many to many relationship- without this relationship we would have no way to express multiple offerings (historical record of past classes).
In this example, there are 4 course offering records
2014 math101 classroom a
2014 english101 classroom b
2015 math101 classroom a
2015 english101 classroom b
That relationship lets us to store and join all of that data together – hope that helps.
You like apples?
Honeycrisp are the best =)
You must be logged in to post a comment.