Answers.Body: <p>We tend to:</p>
  
  <ul>
  <li>not use households but use individual memberships and the inheritance feature to construct Family (Household-like) Memberships  </li>
  <li><p>use Drupal Webform CiviCRM module to make this a one form signup (adults + children on one form) - with Webform CiviCRM you can add more then one Contact on the Form and specify relationships between these
  Contacts</p></li>
  <li><p>use inherit (on the Membership Type config) -> so that the children inherit the Family Membership by relation</p></li>
  </ul>
  
  <p>Example - below (adding Children) - in this case we can't add Spouses - they need to sign their own waiver. But we do get them a Free Spousal membership if they specify a Spousal relationship to the Primary Contact. </p>
  
  <p><a href="https://i.sstatic.net/In3fO.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/In3fO.png" alt="enter image description here"></a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T13:52:50.620Z
Answers.Text: Thanks so much for this example! To make sure I fully understand, you're saying that you create a new relationship type called "inherit," keep the individuals separate (no households), but then assign the "inherit" relationship type to contacts who should share the membership ... is that an accurate summation? I can see how making it "household-like" without it actually being a household will probably make this all fall into place for me so I'll give that a shot. Thanks! (We're on WordPress so I can't use the cool Drupal stuff but that looks slick.)
Answers.UserDisplayName: Matt Woodward
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T23:14:03.247Z
Answers.Text: The relationships are child of/parent of; spouse of/spouse of; The Membership is called Family Membership and then dad or mom is the Primary - both child of and spouse of automatically inherit from the Primary member. That way you create a ‘household’;
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-27T18:18:44.003Z
Answers.Text: Makes sense -- thanks! I implemented this and have been updating a bunch of data, and it's all working really nicely. Thanks so much again for the suggestion. This is a much better solution for what I'm trying to do as opposed to using the Household contact type.
Answers.UserDisplayName: Matt Woodward
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-27T21:56:28.467Z
Answers.Text: Excellent - glad you got that working!
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-10-26T13:27:33.490Z
Answers.LastActivityDate: 2018-10-27T13:18:56.133Z
Answers.LastEditDate: 2018-10-27T13:18:56.133Z
Answers.UserDisplayName: KarinG - Semper IT
Body: <p>In trying various scenarios with memberships that involve multiple contacts (our most common scenario is partners/spouses), where I landed at this point that seems to work best for my needs is to use households, have the membership at a household level, and use the "Household Member is" relationship on the membership type so the membership applies to everyone with that relationship.</p>
  
  <p>The issue I'm running into with this is when I run a membership report it includes each member of the household (which is good!) and ALSO includes the household itself (not so good). Particularly when it comes to generating a membership sign-in list for our meetings (and our meetings can be pretty large), it's not ideal to have the households on the list.</p>
  
  <p>Unless I'm totally missing it, I don't see that you can filter by contact type on the membership reports. If I could limit the contact type to individuals that would solve my problem. I'm comfortable with SQL and could take the query listed on the Developer tab as my starting point, but if I do that am I then in the realm of creating an extension to do this?</p>
  
  <p>I also did a lot of reading up on Households in general and it looks like a lot of people don't use them at all. I could go the "payment by other member" route and do a soft credit but that seems cumbersome to me (you have to create the payment on the NON-paying user FIRST from what I can tell), so given all of this how have others gone about handling memberships with multiple contacts?</p>
  
  <p>Thanks for your thoughts and experiences on this.</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-26T00:43:10.950Z
Comments.Text: so you are using 'inherited memberships' - so does the report not let you filter to either 'primary' or non-primary memberrs the way that it does in Adv Search?
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2018-10-26T13:46:08.607Z
Comments.Text: Thanks for the idea -- the membership reports section doesn't let you filter on primary vs not, but I didn't know that was an option in advanced search so I appreciate you pointing that out. The issue there would be that we have individual members as well so in some cases household would be primary, while in others an individual contact would be. This almost gets me there but then the resultant report doesn't have the member info I want included (status, when the membership expires, etc.). I'll play around with this angle more though. Thanks!
Comments.UserDisplayName: Matt Woodward
Tags: <civimember><households>
Title: Best way to handle memberships involving multiple contacts?
ThreadText: # Best way to handle memberships involving multiple contacts?
  
  (Asked by: username_0 on 2018-10-25)
  
  In trying various scenarios with memberships that involve multiple contacts (our most common scenario is partners/spouses), where I landed at this point that seems to work best for my needs is to use households, have the membership at a household level, and use the "Household Member is" relationship on the membership type so the membership applies to everyone with that relationship.
  
  The issue I'm running into with this is when I run a membership report it includes each member of the household (which is good!) and ALSO includes the household itself (not so good). Particularly when it comes to generating a membership sign-in list for our meetings (and our meetings can be pretty large), it's not ideal to have the households on the list.
  
  Unless I'm totally missing it, I don't see that you can filter by contact type on the membership reports. If I could limit the contact type to individuals that would solve my problem. I'm comfortable with SQL and could take the query listed on the Developer tab as my starting point, but if I do that am I then in the realm of creating an extension to do this?
  
  I also did a lot of reading up on Households in general and it looks like a lot of people don't use them at all. I could go the "payment by other member" route and do a soft credit but that seems cumbersome to me (you have to create the payment on the NON-paying user FIRST from what I can tell), so given all of this how have others gone about handling memberships with multiple contacts?
  
  Thanks for your thoughts and experiences on this.
  
  **Tags:** civimember, households
  
  > **Comments:**
  > **username_1**: so you are using 'inherited memberships' - so does the report not let you filter to either 'primary' or non-primary memberrs the way that it does in Adv Search?  
  > **username_0**: Thanks for the idea -- the membership reports section doesn't let you filter on primary vs not, but I didn't know that was an option in advanced search so I appreciate you pointing that out. The issue there would be that we have individual members as well so in some cases household would be primary, while in others an individual contact would be. This almost gets me there but then the resultant report doesn't have the member info I want included (status, when the membership expires, etc.). I'll play around with this angle more though. Thanks!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-10-26. Score: 5 | Accepted answer
  
  We tend to:
  
  * not use households but use individual memberships and the inheritance feature to construct Family (Household-like) Memberships
  * use Drupal Webform CiviCRM module to make this a one form signup (adults + children on one form) - with Webform CiviCRM you can add more then one Contact on the Form and specify relationships between these
    Contacts
  * use inherit (on the Membership Type config) -> so that the children inherit the Family Membership by relation
  
  Example - below (adding Children) - in this case we can't add Spouses - they need to sign their own waiver. But we do get them a Free Spousal membership if they specify a Spousal relationship to the Primary Contact.
  
  [![enter image description here](https://i.sstatic.net/In3fO.png)](https://i.sstatic.net/In3fO.png)
  
  > **Comments:**
  > **username_0**: Thanks so much for this example! To make sure I fully understand, you're saying that you create a new relationship type called "inherit," keep the individuals separate (no households), but then assign the "inherit" relationship type to contacts who should share the membership ... is that an accurate summation? I can see how making it "household-like" without it actually being a household will probably make this all fall into place for me so I'll give that a shot. Thanks! (We're on WordPress so I can't use the cool Drupal stuff but that looks slick.)  
  > **username_2**: The relationships are child of/parent of; spouse of/spouse of; The Membership is called Family Membership and then dad or mom is the Primary - both child of and spouse of automatically inherit from the Primary member. That way you create a ‘household’;  
  > **username_0**: Makes sense -- thanks! I implemented this and have been updating a bunch of data, and it's all working really nicely. Thanks so much again for the suggestion. This is a much better solution for what I'm trying to do as opposed to using the Household contact type.  
  > **username_2**: Excellent - glad you got that working!  
  
  ---
  
  