CiviCRM Community Forums (archive)

Knowing what you want is probably the biggest thing, and it sounds like you do.
I'm not sure if it's possible to create a "one-size-fits-all" checklist for setting up CiviCRM.
There aren't too many decisions you make now that you can't take back later (although doing so will always cost some time & money). For example, if you pick the wrong host, you can switch later.
But mapping your data is one decision it would be very hard to do over. So planning out how you will use contact types, groups, tags, smart groups, and custom data now (and getting it right) can save you a lot of headache in the future.
Some resources on that:
http://book.civicrm.org/user/current/organising-your-data/overview/
http://civiteacher.com/ (see Groups vs Tags video at the bottom of the page)

It can be pretty daunting trying to get your head around all of the options. As you have a test system installed I would encourage you to spend time with that and the user/admin guide in order to gain a better understanding of what you can do (and what you can't). There is plenty of help and guidance available through this forum as well, and of course if you have the budget you can hire some professional expertise from one of the many partners listed at https://civicrm.org/providers

In terms of membership types, CiviCRM gives you the option to create a membership type that has a monthly cycle, which might well suit your needs. Set it up in your sandbox and test it out with the rest of your workflow - payment processor, contribution pages, etc., and see if it works for you.

How, and whether, you use contact types, groups and tags is as much a matter of personal preference as it is driven by your business processes and workflows. If you want to use targeted bulk mailings then you'll need to use groups for that. Take care when using groups for classification/categorisation and for mailings, as when someone unsubscribes form a mailing list, they are removing themselves from your group, so if that same group is used for categorisation, or is used for access control purposes, you can quickly get into a mess. Tags are lightweight and can be used for a whole range of purposes.

If you want to collect custom data on some types of contacts but not others then using different contact types, and perhaps sub-types, is your friend there.

In short - they don't. what I mean is that contact types don't particularly relate to groups or tags, or tags to groups, unless you want them to.

To explain more, Civi comes with three contact types out of the box (Individuals, Households and Organisations). Pretty self explanatory. You might choose to simply go with those. You might find that you have some clear groupings for different types of individuals, in that for (students, lets say) you might need to collect different data than for pensioners, and you want to have different sets of custom fields for each. In that case you can create sub-types for students and pensioners, and then link the custom fields to those particular sub-types, so your screens don't get cluttered with pensioner specific fields for individuals that aren't pensioners.

Pensioners might be classified into various groups, and you could use groups or smart groups to do that, especially if you want to use those groups for targeted mailings or for access control. Otherwise you could also use tags. Or you might want to use tags in a different way. It's up to you.

I think the place to start is to understand what your real data needs to look like in order for you to achieve your goals, and then everything will flow from that.

At first glance - and without knowing your organisation or its constituencies, my guess would be that a single individual could potentially fit into most or all of those categories.

Certainly members will be defined as any contact that has a valid membership, so any custom data specific to the membership could be associated with the membership record rather than the contact record if that suits your requirement, so a smart group based on membership type and status could be used to categorise your members.

Likewise Donors will presumably be specified as a contact that has made a donation. As you have donation (contribution) records in the system you could categorise donors as a smart group based on whether the contact has made a donation.

If we assume that a subscriber has opted into a mailing list, then that mailing list group defines contacts as subscribers. If they have paid a fee for the mailed newsletter, then you'll be able to find them and place them automatically in a smart group based on that transaction.

I'd guess that you would probably want to collect some custom data on Volunteers, so that might be useful as a contact sub-type, depending on your workflows and data requirements.

If you want to control access to content then you can do that easily in Drupal via memberships and groups (not sure about Wordpress or Joomla!?).

If you have monthly memberships and annual memberships, these could be different membership types that your contacts could sign up for. And smart groups (which are effectively saved searches) could help you to find, list and manage them.

A smart group, because it is a search, is dynamic: contacts will fall in or out of the group based on the search criteria. You can also manually add or remove contacts from a smart group, and that overrides the search criteria.

You could again use smart groups to identify large donors (the saved search might find all contacts with a donation of €1000 or over made in the last year, for example). Likewise small donors.

Hope this helps.

In general you want to minimize 2 things:
- Manual work on your part
- Redundant data

For example, if you set about tagging everyone who has given money with a "donor" tag, then you are both creating more work for yourself and opening yourself up to data-integrity problems. Because what happens if you forget to tag someone as a "donor" but they've given money? This is an example of redundant data because being a donor is already evident in the fact that they have a contribution record. You can see this on their contact summary page. You can search for donors and create reports on them. There is no need to tag them as well. If you really want to you can create a smart group for them (which isn't manual work to keep up and isn't redundant because it's simply a reference to data, not a separate store of data) but you may not even need to do that.

The golden rule is "don't store the same information in 2 places". People are donors by virtue of the fact that they have a contribution record. People are members by virtue of the fact that they have an active membership record. The list goes on (people are Americans by virtue of the fact they have an address in the US).

I only consider using groups, tags, and contact subtypes if there is absolutely no other way of getting at that data. Smart groups are nice for creating automatic mailing lists (e.g. a smart group of everyone who attended a conference). Tags are simplistic and I avoid them for anything other than sort term "throw-away" use (like quickly tagging all the contacts I need to mail this week, can delete the tag later). Contact types are also a pain because they have to be manually updated, and are really only useful for segregating custom data.