2

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!

Improve this question
7
  • 2
    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
    – petednz - fuzion ♦
    Commented Aug 10, 2015 at 2:56
  • 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.
    – Russell Ault
    Commented Aug 10, 2015 at 17:55
  • 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.
    – petednz - fuzion ♦
    Commented Aug 10, 2015 at 20:59
  • 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?
    – Russell Ault
    Commented Aug 11, 2015 at 21:29
  • 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.
    – petednz - fuzion ♦
    Commented Aug 12, 2015 at 2:41

2 Answers 2

Reset to default
1

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

Improve this answer
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.

Improve this answer
2
  • 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.
    – Russell Ault
    Commented Aug 17, 2015 at 19:07
  • 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.
    – Nicholai
    Commented Aug 17, 2015 at 20:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.