Many to Many Relationships

[youtube id=Jy5JZ42XN6Q]

32 thoughts on “Many to Many Relationships”

  1. 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?

  2. Hello

    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 ?

    1. 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.

  3. 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?

  4. 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?

  5. Here is a use case question:
    I have custom object A that is related to both accounts and opportunities.
    Requirement:
    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.

    Solution:(?)
    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.

    Question:
    how to prevent a deleted opportunity from purging custom object A records.

    1. Close-
      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

  6. 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?

    1. 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.

          1. 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

  7. 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?

  8. 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?

    1. Good question

      2014
      MATH101 is offered in classroom A – 25 students
      ENGLISH101 is offered in classroom B – 30 students

      A max occupancy 25
      B max occupancy 40

      2015
      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.

Leave a Reply