Answers.Body: <p>Drupal users can (should) only be associated with an individual contact record but with a correctly set up 'on behalf of' workflow this can allow for an Individual to purchase a membership on behalf of an organisation. (I say 'should' because I know users have overridden this and hence permitted the Drupal user to have a uf_match link to the Org record)</p>
  
  <p>Provided they get a Permissions 'current employer of' relationship, they should then be able to return to a renewal page and have the option of renewing on behalf of the original organisation (or any other organisations they have permissioned current employer relationship with), or join on behalf of a new one.</p>
  
  <p>Inheriting of memberships does not need to be set on the Employer of relationship if you don't want that, eg you could use a Primary Contact for relationship so that only specified individuals 'inherit'. This can help when it comes to sending out reminders.</p>
  
  <p>In terms of Households, we have mostly shied away from using that concept altogether since it does not work with 'on behalf of'. I suspect it is not much work to make this possible, and have flagged it in the past, but no one has funded it, and we have always preferred our work arounds of either having sub-Organisation types, or using Webforms to manage the relationships.</p>
  
  <p>The whole 'on behalf of' can be tricky to get right but there won't be one magic solution that meets all needs.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-03-10T20:01:55.627Z
Answers.LastActivityDate: 2017-03-10T20:01:55.627Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>My question is related to how drupal users interact with their civicrm membership and contact record.</p>
  
  <p>In 2013 we moved to using CiviCRM. We already had 'Group' and 'Household' membership types, so it was assumed that the Civi membership would be housed on Organisation and Household contact records, and the membership inherited by related Individual records.</p>
  
  <p>However in the following years I've been wondering if we got that wrong, as there are several reasons why this doesn't work:</p>
  
  <p>1) Drupal users can only be associated with an individual contact record, so they would not be able to renew a membership online if it is housed on a Household or Organisation record; they would probably end up creating a brand new membership but on their Individual record.</p>
  
  <p>2) The CiviContribute pages allow for a user to join on behalf of an organisation, but when this takes place the membership is by default added to the individual's record - the relationship of 'employed by' is created by default to link to the Organisation record (which only gives inheritance to that record if the relationship for that membership is set up using that relationship.)</p>
  
  <p>3) If a membership housed on an individual record is renewed online, the membership inheritance does not seem to renew the membership on the Organisation record, but at least the individual still has an active membership and therefore able to use and drupal related benefits associated with current membership.</p>
  
  <p>So I am not sure how CiviCRM is actually meant to be used in this scenario - should we actually house the membership on an individual record by default and allow access via Webform to allow them to create their related Household or Organisation contact records? </p>
  
  <p>Please let me know if you need any more details!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-03-10T16:47:25.840Z
Comments.Text: Your first reason isn't strictly speaking correct.  Drupal users can be associated with households.  Practically, having to setup online sign up for membership, registration, donations, etc. that have the option for either household or individual and making it easily can be a challenge.  (In our organization's opinion the biggest weakness and the reason we may some day ditch civi is the way it handles households and individuals.  Way too much adiministrivia to keep things correct and clean.)
Comments.UserDisplayName: Paul-Tahoe
Tags: <civimember><households>
Title: Which contact record should house the membership?
ThreadText: # Which contact record should house the membership?
  
  (Asked by: username_0 on 2017-03-10)
  
  My question is related to how drupal users interact with their civicrm membership and contact record.
  
  In 2013 we moved to using CiviCRM. We already had 'Group' and 'Household' membership types, so it was assumed that the Civi membership would be housed on Organisation and Household contact records, and the membership inherited by related Individual records.
  
  However in the following years I've been wondering if we got that wrong, as there are several reasons why this doesn't work:
  
  1) Drupal users can only be associated with an individual contact record, so they would not be able to renew a membership online if it is housed on a Household or Organisation record; they would probably end up creating a brand new membership but on their Individual record.
  
  2) The CiviContribute pages allow for a user to join on behalf of an organisation, but when this takes place the membership is by default added to the individual's record - the relationship of 'employed by' is created by default to link to the Organisation record (which only gives inheritance to that record if the relationship for that membership is set up using that relationship.)
  
  3) If a membership housed on an individual record is renewed online, the membership inheritance does not seem to renew the membership on the Organisation record, but at least the individual still has an active membership and therefore able to use and drupal related benefits associated with current membership.
  
  So I am not sure how CiviCRM is actually meant to be used in this scenario - should we actually house the membership on an individual record by default and allow access via Webform to allow them to create their related Household or Organisation contact records?
  
  Please let me know if you need any more details!
  
  **Tags:** civimember, households
  
  > **Comments:**
  > **username_1**: Your first reason isn't strictly speaking correct.  Drupal users can be associated with households.  Practically, having to setup online sign up for membership, registration, donations, etc. that have the option for either household or individual and making it easily can be a challenge.  (In our organization's opinion the biggest weakness and the reason we may some day ditch civi is the way it handles households and individuals.  Way too much adiministrivia to keep things correct and clean.)  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-03-10. Score: 3
  
  Drupal users can (should) only be associated with an individual contact record but with a correctly set up 'on behalf of' workflow this can allow for an Individual to purchase a membership on behalf of an organisation. (I say 'should' because I know users have overridden this and hence permitted the Drupal user to have a uf\_match link to the Org record)
  
  Provided they get a Permissions 'current employer of' relationship, they should then be able to return to a renewal page and have the option of renewing on behalf of the original organisation (or any other organisations they have permissioned current employer relationship with), or join on behalf of a new one.
  
  Inheriting of memberships does not need to be set on the Employer of relationship if you don't want that, eg you could use a Primary Contact for relationship so that only specified individuals 'inherit'. This can help when it comes to sending out reminders.
  
  In terms of Households, we have mostly shied away from using that concept altogether since it does not work with 'on behalf of'. I suspect it is not much work to make this possible, and have flagged it in the past, but no one has funded it, and we have always preferred our work arounds of either having sub-Organisation types, or using Webforms to manage the relationships.
  
  The whole 'on behalf of' can be tricky to get right but there won't be one magic solution that meets all needs.
  
  
  ---
  
  