Contacts vs Groups vs Memberships vs Profiles vs Tags

[cudder23]

I'm familiar with Drupal but new to CiviCRM.

I'm reading through the extensive documentation at book.civicrm.org. I see that it is important to organize the data to take advantage of the tools built into CiviCRM, but I'm confused about which of the various tools of CiviCRM are appropriate, and how to organize the data I'm bringing in, so any help or advice for resources would be very appreciated.

The work I'm doing is for a small member-based non-profit. They have three types of memberships that are currently tracked using an access database.

The New CiviCRM website should have the following features (among others):

1. Three types of Memberships: Full, Associate and Student.

• Collect basic info from all members (name, address, phone, email, organization) but also collect specific additional information for different types of memberships (e.g. specialized training, certifications, skills, reason for wanting to join).
• All of these are annual memberships that renew on Jan 1.
• An Associate or Student Member can upgrade to a Full Member after 1 year of membership.
• Applications for membership and payment (via PayPal Standard), which I'm planning to implement through Webform CiviCRM integration module.

2. Public listings of members, with different info displayed based on type of membership.

3. Members of different types will get different levels of access to content on the site

4. A subcategory of Full Members is Board Members who will get special access to board meeting notes, etc.

• Board Members have specific titles that also need to be set (President, Treasurer, etc.)

So, for #1: What is the best way to collect the Membership specific information for each type of membership? Does it make more sense to:

• add three new Contact Types (based on the built-in "Individual") and add unique custom fields for each type of member?
• create three Membership Types and add custom fields to those?

And I want to be able to change a Member from one type to another, so does this argue for using Memberships vs Contact Types?

For #2: Will the decision in #1 impact what I can do with Views when I'm creating the Public Listings of Members? Is Profile part of controlling how Views are generated? Or does one have full Views control without using Profile?

#3: Should the Memberships be associated with Groups to control access to different parts of the site?

#4: Should Board Member status be a Tag? a Group? a Contact Type? And how to set up Board Member positions within this?

I did find this presentation:
http://civicrm.tw/sites/civicrm.tw/files/transitioning_to_civicrm_-_presentation_for_civicon_2014.pdf

which was helpful as far as it went, but the exercises for how to organize the data were apparently done during the presentation and there is no information in the slides as to how the various examples should be organized.

If anyone has links to other tutorials or similar training on how to understand the CiviCRM structure and what makes sense to put where, that would be great.

Thanks!

[Coleman Watts]

1) I'd go with membership types. They can be self-service, even changed by the end-user if you wish (called "membership upsell") via contribution pages or drupal webforms.

2) Drupal Views or a CiviCRM profile.

3) Enable the bundled "CiviMember Roles Sync" module, and define your roles and permissions however you wish.

4) A Civi group synced with a drupal role (via the "CiviGroup Roles Sync" module, also bundled) might make the most sense. The group would be useful to send mailings to your board members), and you'd need the role if they needed special privileges.

[petednz]

+1

[cudder23]

Thank you, Coleman, this is very helpful.

I'm starting to get my head around how CiviCRM works and where in CiviCRM it makes sense to put the data this organization wants to collect and track. I'm coming to appreciate just how powerful CiviCRM is, and how great a tool the Webform CiviCRM integration module is.

I hope these questions aren't too specific to be helpful to others, but I still have a couple of clarifications about where it makes sense to put data. The reason I'm clarifying this is because it's apparently impossible to backtrack if you choose the wrong scope for a Custom Field Set:

The scope of a custom field set is one of the few decisions that is irreversible (you will not be able to change it after creating it) so it is important to consider carefully what you want to associate your custom field set with when you start.

http://book.civicrm.org/user/current/organising-your-data/custom-fields/

So I want to be sure I understand the design of CiviCRM and what is meant to go where...

1) Membership Types

Would you recommend that any fields/data that are common to all Members (a required type of certification, for example) should be put into a Custom Field Set for a custom Contact Type (i.e. "Member" based on "Individual")?

And then those fields/data specific to a given type of Membership (e.g. an "Educational Program" field for the Student Membership, a "Training" field for the Full Membership) would be in a Custom Field Set associated with each of the CiviCRM Membership types?

Or is it better to keep the Contact Types simple with only basic Contact details (name, address, phone, email) and put all customized, specialized data into Custom Field Sets associated with Memberships (some associated with all Memberships, some with specific ones), since that data is more related to the Membership anyway?

4) Board Member Position

Thank you. CiviGroup Roles Sync does sounds like the right tool to single out those Members (Full, Assoc. Student) that are also Board Members, and then be able to send emails to that Group and control content access via a "Board Member" role on the Drupal side.

As far as the Board Member Position ("President", "Treasurer", etc.), would that be best handled with Tags? It is important that this be something only the Site Admin can change. And that it be simple to change and then display a Board Member list with their positions listed. (I'm assuming Drupal Views can get a hold of Tags too...)

Or would it be better to have the Board Member Position be in a Custom Field set associated with the Board Member Group (though Group Custom fields are not searchable...)?

[petednz]

In terms of whether fields should be on a Contact or on a Membership, if the data is something you should have about a contact 'only' if they have a membership, and if that data might change from membership year to membership year, or even membership type to membership type, then yes put the field on the Membership rather than the contact.

For example, if when a Person gets a membership you want to ask them 'what is the most recent date you got a First Aid Certificate', or 'what type of drivers licence do you hold' then they seem to be fields that the person should update each time they rejoin, and is info you don't need about non-members - hence add the fields to the Membership

Hope that helps

Usually I think of case to do with Participants where you might want to find out what flight they arrive on to a Conference - obviously that data will be different for each conference they attend, and hence i would add that field to the Participant record for those conferences, not to the Contact Record.

[cudder23]

2) Drupal Views vs CiviCRM Profiles

Is it true that CiviCRM Profiles can be used like Drupal Views? What are the differences? Is one more flexible than the other?

My understanding is that Drupal Views can access any data fields in CiviCRM and display it in customized ways like any other Drupal Content.

CiviCRM Profiles, on the other hand, seems to be a way to control what is displayed through the CiviCRM interface (search results, directory, etc.). But from what I understand CiviCRM output is a bit harder to style and manage, especially for someone like me who is comfortable in Views.

Coleman, you suggested in my Pre-Installation posting that I might create two View blocks to display different member listings. So that would be instead of Profiles, not using Profiles to inform the View somehow, right?

1) Membership Types (continued)

One important aspect of the site is a search tool for the Full Members. They have varied qualifications and the users of the site will need to be able to search for Full Members who have certain qualifications that fit their needs.

So, how best to store the data so it's accessible for searching?

There should be a set of checkboxes so Full Members can check various qualifications:

[ ] Certification A
[ ] Certification B
[ ] Certification C

The public user of the site is given a search tool with the same choices to find members who have, for example Certification A.

Should these fields be part of a Custom Field Set of the Full Membership type? If they are set up as Custom Fields for the Membership, will these fields be searchable in this way?

[cudder23]

Thank you petednz. This is very helpful.

So, in my example I would include those Certification checkboxes as part of a Custom Field Set in the various Membership Types.

[petednz]

Views gives you more flexibility, eg you can daisy chain information together such as about an employee (their qualifications) and their Employer (their professional status, address, business focus etc) by using Drupal Views 'relationships' to pull them together.

From what you sound like you need I would be going down the Views route first.

And yes, to answer your question of Coleman, if you want Blocks to show membership data, then that is pure Views, nothing to do with civi profiles. Think of them as alternatives, but for many cases, we find Views gives greater flexibility as well as features that Profiles don't have.

I suggest you start getting some fields added to Memberships, knocking some Views in to shape and getting a sense of what is possible.

[Coleman Watts]

IMO building a rough prototype on a sandbox site, and then throwing away the prototype and starting fresh on your real site, is not wasted time. If you're too worried about getting it perfect the first time you won't have any chance to experiment, try things, and make mistakes.

[petednz]

And you can export Views from sandbox and import (as User 1) on the real site.