Answers.Body: <p>We ended up going with option c): create each choir as its own contact, then create custom relationships between the choirs and the organization they're a part of. This in addition to making the choirs themselves easily searchable, this also allows us to create separate relationships between conductors and their individual choirs (since each choir in an organization might have a different conductor).</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-11T05:45:44.280Z
Answers.LastActivityDate: 2015-09-29T20:24:43.533Z
Answers.LastEditDate: 2015-09-29T20:24:43.533Z
Answers.UserDisplayName: Russell Ault
Answers.Body: <p>I'm a fan of your 'B' option, and here's why. If we tie the information to a membership, won't they have to retype everything each time they renew? Could that leave things in a weird place with reporting or search when an org has a long membership history with different information in each membership? </p>
  
  <p>Maybe down the road you're trying to set up some contract events with a school system. You want to find members who manage choirs with at least 20 singers. But with this info tied to the membership, you could get false positives with choirs who have shrunk, or false negatives with choirs who have grown. I don't have the full context of what your goal is by knowing these details, so this is just something to consider.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-17T19:07:04.733Z
Answers.Text: Correct me if I'm wrong, but my impression was that when memberships are renewed, it simply extends the term of an existing membership, rather than creating a whole new one (in fact, if I try to create a new membership of the same type for an existing member, it asks me if I'd rather renew the existing membership instead), so this shouldn't be an issue.
Answers.UserDisplayName: Russell Ault
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-17T20:27:47.483Z
Answers.Text: I just did some tests and you're correct. I thought custom fields were tied to the membership transaction, but it appears they stay on the membership record itself. I'm still a fan of option B however. If you use a finite number of fields, your searches and smart groups will look like "Chorus 1 # Singers > 20 OR Chorus 2 # Singers > 20 OR Chorus 3 #Singers >20". It seems like a situation that allows extra opportunity for user error.
Answers.UserDisplayName: Nicholai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-08-15T22:46:49.587Z
Answers.LastActivityDate: 2015-08-15T22:46:49.587Z
Answers.UserDisplayName: Nicholai
Body: <p>Short version: Using the standard New Custom Field Set form, it is currently not possible to create a multiple-record field set for memberships. Is there some other way to achieve this?</p>
  
  <p>Long version: I work for a membership-based society comprised of, among other things, a number of choral music organizations. As part of their being members, we would like them to tell us the names of the choirs that are part of their organization, and the number of singers in each choir. Given that a single organization can run multiple choirs, a multiple-record field set would be perfect for this information...if only I could create one. Using CiviCRM's built-in facilities, the only options I can see available to me are:</p>
  
  <p>a) creating a finite series of separate fields for the membership type based on some reasonably safe assumptions about the maximum number of choirs a single organization is likely to have, or</p>
  
  <p>b) creating a new contact type specific to these members, creating a multiple-record field set to associate with it, and then forcing someone in the office to update the information manually.</p>
  
  <p>At present I'm leaning toward the first option, but I'd love to hear if anyone has any other ideas, especially ones that would allow me to use the correct (for the situation) field set type associated with the membership scope.</p>
  
  <p>Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-10T02:56:17.480Z
Comments.Text: What CMS are you on? If Drupal then some other options may be available such as using Webforms, and having the 'music organisation' create Contact records with numbers of singers for each of their Choirs
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-10T17:55:30.820Z
Comments.Text: We are using Drupal 7, but we're doing a two-stage roll-out of internal use first, then opening up to public registration (our current system doesn't have a public-facing side, and I only want to re-educate one group users at a time), so I'd like to be able to do this entirely within CiviCRM. At one point I had considered creating a contact for each separate choir, but given that the only info we care about for a given choir is how many singers are in it, this seems like serious overkill, so I was hoping to keep that information within the member contact's information set.
Comments.UserDisplayName: Russell Ault
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-10T20:59:49.363Z
Comments.Text: Understood. And the 'number of choirs and number of singers' is data you want added/updated each time they renew? I think the option a/ you outline is the way to go then.  I am sure someone could suggest some js solution so that instead of seeing all the unnecessary extra fields on the form, you could provide an 'add another' link which reveals the next set of fields.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-11T21:29:58.173Z
Comments.Text: Absolutely right on the renewal update. It's not a tonne of fields anyway (I think the most choirs any one organization currently runs is 4 or 5). Any idea why CiviMember doesn't support multiple-record fieldsets?
Comments.UserDisplayName: Russell Ault
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-12T02:41:17.393Z
Comments.Text: Nobody has tweaked it for that purpose ;-) Also there have been constraints wrt multiple record fields in terms of import/export/profiles/tokens etc though most of those I think have been resolved now for Contact-based fields. It may not be a major mission to allow multple record fields for a different 'entity' type but would probably require you talking to a development shop unless you are well adept yourself.
Comments.UserDisplayName: petednz - fuzion
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-15T18:45:37.013Z
Comments.Text: I'm more than happy to poke around in the code, although I'm always wary of making changes to the base source code of CiviCRM (I'm afraid of breaking update compatibility). What makes multiple-entry fieldsets so different that they need special handling?
Comments.UserDisplayName: Russell Ault
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-08-15T21:01:27.577Z
Comments.Text: I can't answer that other than to say that to avoid 'breaking updates' any poking would hopefully result in a PR to get your improvements added back to core. A search in JIRA points to lots of previous tickets relating to 'multiple records' and beyond that I can only suggest you raise the issue on IRC and hope a core developer is around to point you in the right direct. hope that helps a bit. https://issues.civicrm.org/jira/browse/CRM-10771?jql=text%20~%20%22multiple%20record%22
Comments.UserDisplayName: petednz - fuzion
Tags: <civimember><custom-fields>
Title: How to create a multiple-record custom field set for a Membership?
ThreadText: # How to create a multiple-record custom field set for a Membership?
  
  (Asked by: username_0 on 2015-08-10)
  
  Short version: Using the standard New Custom Field Set form, it is currently not possible to create a multiple-record field set for memberships. Is there some other way to achieve this?
  
  Long version: I work for a membership-based society comprised of, among other things, a number of choral music organizations. As part of their being members, we would like them to tell us the names of the choirs that are part of their organization, and the number of singers in each choir. Given that a single organization can run multiple choirs, a multiple-record field set would be perfect for this information...if only I could create one. Using CiviCRM's built-in facilities, the only options I can see available to me are:
  
  a) creating a finite series of separate fields for the membership type based on some reasonably safe assumptions about the maximum number of choirs a single organization is likely to have, or
  
  b) creating a new contact type specific to these members, creating a multiple-record field set to associate with it, and then forcing someone in the office to update the information manually.
  
  At present I'm leaning toward the first option, but I'd love to hear if anyone has any other ideas, especially ones that would allow me to use the correct (for the situation) field set type associated with the membership scope.
  
  Thanks!
  
  **Tags:** civimember, custom-fields
  
  > **Comments:**
  > **username_1**: What CMS are you on? If Drupal then some other options may be available such as using Webforms, and having the 'music organisation' create Contact records with numbers of singers for each of their Choirs  
  > **username_0**: We are using Drupal 7, but we're doing a two-stage roll-out of internal use first, then opening up to public registration (our current system doesn't have a public-facing side, and I only want to re-educate one group users at a time), so I'd like to be able to do this entirely within CiviCRM. At one point I had considered creating a contact for each separate choir, but given that the only info we care about for a given choir is how many singers are in it, this seems like serious overkill, so I was hoping to keep that information within the member contact's information set.  
  > **username_1**: Understood. And the 'number of choirs and number of singers' is data you want added/updated each time they renew? I think the option a/ you outline is the way to go then.  I am sure someone could suggest some js solution so that instead of seeing all the unnecessary extra fields on the form, you could provide an 'add another' link which reveals the next set of fields.  
  > **username_0**: Absolutely right on the renewal update. It's not a tonne of fields anyway (I think the most choirs any one organization currently runs is 4 or 5). Any idea why CiviMember doesn't support multiple-record fieldsets?  
  > **username_1**: Nobody has tweaked it for that purpose ;-) Also there have been constraints wrt multiple record fields in terms of import/export/profiles/tokens etc though most of those I think have been resolved now for Contact-based fields. It may not be a major mission to allow multple record fields for a different 'entity' type but would probably require you talking to a development shop unless you are well adept yourself.  
  > **username_0**: I'm more than happy to poke around in the code, although I'm always wary of making changes to the base source code of CiviCRM (I'm afraid of breaking update compatibility). What makes multiple-entry fieldsets so different that they need special handling?  
  > **username_1**: I can't answer that other than to say that to avoid 'breaking updates' any poking would hopefully result in a PR to get your improvements added back to core. A search in JIRA points to lots of previous tickets relating to 'multiple records' and beyond that I can only suggest you raise the issue on IRC and hope a core developer is around to point you in the right direct. hope that helps a bit. https://issues.civicrm.org/jira/browse/CRM-10771?jql=text%20~%20%22multiple%20record%22  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_0 on 2015-09-11. Score: 1 | Accepted answer
  
  We ended up going with option c): create each choir as its own contact, then create custom relationships between the choirs and the organization they're a part of. This in addition to making the choirs themselves easily searchable, this also allows us to create separate relationships between conductors and their individual choirs (since each choir in an organization might have a different conductor).
  
  
  ---
  
  ### Answer by username_2 on 2015-08-15. Score: 0
  
  I'm a fan of your 'B' option, and here's why. If we tie the information to a membership, won't they have to retype everything each time they renew? Could that leave things in a weird place with reporting or search when an org has a long membership history with different information in each membership?
  
  Maybe down the road you're trying to set up some contract events with a school system. You want to find members who manage choirs with at least 20 singers. But with this info tied to the membership, you could get false positives with choirs who have shrunk, or false negatives with choirs who have grown. I don't have the full context of what your goal is by knowing these details, so this is just something to consider.
  
  > **Comments:**
  > **username_0**: Correct me if I'm wrong, but my impression was that when memberships are renewed, it simply extends the term of an existing membership, rather than creating a whole new one (in fact, if I try to create a new membership of the same type for an existing member, it asks me if I'd rather renew the existing membership instead), so this shouldn't be an issue.  
  > **username_2**: I just did some tests and you're correct. I thought custom fields were tied to the membership transaction, but it appears they stay on the membership record itself. I'm still a fan of option B however. If you use a finite number of fields, your searches and smart groups will look like "Chorus 1 # Singers > 20 OR Chorus 2 # Singers > 20 OR Chorus 3 #Singers >20". It seems like a situation that allows extra opportunity for user error.  
  
  ---
  
  