CiviCRM Community Forums (archive)

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.

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

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?

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.

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