CiviCRM Community Forums (archive)

Hi all,

I'm new here. I'm based in Wellington, NZ and I'm evaluating CiviCRM for a medium size non-profit medieval recreation group I am a member of (the New Zealand and Australian arms of The Society for Creative Anachronism, for those of you who've heard of it). I started another thread with a specific question about membership cards. This is a more general explanation of what our organisation needs. CiviCRM looks like a very close fit, but it is going to need some work to do everything we want. I'm a network engineer by trade rather than a programmer so getting the system installed and running isn't a big deal (I've already got a sandbox set up using Drupal6), but I lack the PHP/MySQL skills to get my head around the code.

First I'll outline the structure of our group, and then get into more detail about what it is we're after.

We're a medieval recreation society with a slightly convoluted structure: there are two real-world incorporations (AU and NZ) and the "in-game" structure of the medieval society. The society carries out a huge range of activities from large scale camping events to small dances, classes, feasts, and recreation martial arts[1].

There is an overarching organisational unit (the kingdom) which encompasses Australia and New Zealand but which is not a legal entity in its own right.  There are two legal entities, one for New Zealand (the SCANZ) and one for Australia (The SCAA). Each entity has their own registrar who processes memberships. We have local branches, but they don't do membership processing on their own.

There are really three parallel organisational structures and there are officers at all levels:
- Kingdom > local groups > sub-groups; and
- SCAA
- SCANZ

The SCAA and SCANZ only really exist to be the legal framework for membership, insurance, ownership of assets etc. The majority of the organisational structure of the society comes from the 'imaginary' side of things, the Kingdom, it's sub groups and the officers and active members at various levels. The SCAA and SCANZ each have a board of three to five members, as well as a registrar and a treasurer.

The society has several branches around Australia and New Zealand, some of which have their own sub-branches in turn. Each branch has its own set of officers, who are required to be paid up members. There are also a number of officers at the 'kingdom' level to whom the branch officers are responsible.

Branches are defined along postcode boundaries in Australia, and along telephone area code boundaries in New Zealand, since NZ's postcode system is a bit random.

Because membership is not compulsory to participate (but it is in order to be an officer) we need to be able to track attributes against contacts who are not members.

Every branch must maintain a minimum number of paid members in order to retain its branch status, so it is important to be able to track paid members by branch in a hierarchical fashion.

Each paid member is issued a membership number that stays with them for life. This needs to be either filled in by hand for members who have come to us from affiliate organisations elsewhere in the world or autogenerated from a defined pool of numbers if the person is a brand new member. Membership numbers must be unique.

Bar the membership numbers and the physical card printing, I think I can deal with all of that out of the box using organisations, different membership types, and groups. I'm not sure whether to define branches as groups, dynamic groups, or organisations.

Every contact has two names we need to track, their legal name and their 'society name'. Part of the way the club operates is that participants have a medieval name they use at society events. Both legal and society names appear on membership cards and rosters of officers etc.

That's the basic membership/officer structure. Out of the box it's mostly all doable, it's just a question of what the best way to organise it with CiviCRM's available tools is and then work out how to present it to volunteer registrars who aren't necessarily at all technical.

The bit I'm really not sure how to do is track our other authorisations.

We have a number of participants, not necessarily paid members, who take part in various forms of medieval and renaissance reenactment combat. In order to take part in combat-related activities these people need to pass a test and be "authorised". Authorisations expire after four years, and there are around 20 different categories we need to keep track of. Authorisations function almost exactly like memberships, except that they aren't memberships. If I could take CiviMember and search-replace "member" with "authorisation" and have it running alongside CiviMember it would be near perfect for what I need to do. I haven't delved into whether or not that's actually possible though.

To complicate matters further, when a new person is authorised, we have to check that the marshal who did their test and signed off their paperwork is currently both authorised and a paid up member. We also need to check that people who submit paperwork to become authorised as marshals are paid up members as well.

Both paid members and people with combat authorisations need to be issued with printed cards.

Our current systems don't allow this at all and because we have two separate membership databases and two separate authorisation databases, it's all a bit ugly right now. Getting all the data into the same system would be a huge benefit to us.

There. I hope that all made sense 

[1] You can see a bit of what we do at http://scademo.com/

CiviCRM 3.1 will allow you to create groups of custom fields which extend a set of membership types (rather than a single membership type) - which should help with your data storage requirements for Authorisations vs. Memberships. You MIGHT be able to use hooks to modify the terminology used (member vs authorisation) based on a URL - but not sure about that.

CiviCRM 3.1 will allow you to create groups of custom fields which extend a set of membership types (rather than a single membership type) - which should help with your data storage requirements for Authorisations vs. Memberships. You MIGHT be able to use hooks to modify the terminology used (member vs authorisation) based on a URL - but not sure about that.

That sounds promising. I had a play with custom data groups in 3.0.1 and it didn't quite do what we need. We can record them there but there's no means I could see to make them expire etc.

Is that functionality in SVN yet?

Thanks Dave, I'll keep an eye on it.