On every installation, you need to categorise your contacts, by what they are (journalists, volunteers, members of your organisations, big donors, politicians...), by what they are interested in (a specific topic, a specific region, age group, type of activity you offer...), by how you interact with them (do they receive your mailing list ? are they invited to your next event....)
As any topology problem, there isn't a unique right way of grouping, and no matter how carefully you plan it, it will evolve, because your organisation changes and offer new services or focus on new topics, and because the world around you evolves too.
Moreover, each way of organising your contacts isn't unique: you can have a journalist that is also a volunteer interested by working for elderly people and that has subscribed to your newsletter). Luckily, CiviCRM offers you several ways of clustering your contacts, and it allows you have several of these way of grouping your contacts simultaneously.
I'll quickly review the tools CiviCRM offers. On every project, we face the same questions: what are the pros and cons of each of these, and most importantly, which one(s) to use for this specific category. Overtime, we've developed some guidelines we'll share with you, hope that will help you as well.
Tools to categorise your contacts
A group in CiviCRM can be either a mailing group, or used to define access rights.
No way of defining the type of relation between the group and the member (eg. you can't be president or substitute member, you are a member or not)
Quickly becomes a mess with zillion groups
If you need to grant a different access right to your volunteers than to the members of your board, that's likely that you will want to use a group. Likewise, if you want to send mass mailing to them.
However, you can create "smart groups", and if you can define a criteria (all the male living in california below 35 and tagged "vegetarian" and "interested by surf"), you can create a group out of it, and its member list will automatically adjust if any of the underlying variables change).
To make them useful, you should try keeping the numbers of groups "low enough". If you use groups for every category, it will end up as something that is just too complicated too use.
good hierarchy (since 2.2)
Well visible in the summary page
Less features bound to them than the groups
No way of defining the type of relation between the tag and the contact (eg. you can't be "freelance" journalist, or "accredited" or "major media")
When you tag a contact "journalist", it is directly visible in the main page of the contact. That's a good way of making clear that this contact belongs to a category. As you can organise the tags into a tree,you can have lots and still have a usable interface
can have more that a simple "belong/doesn't belong"
easier to set the layout
harder to use to search the members (you need advanced search)
if you need to be able to enter a date or a number (eg number of children), custom tags are for you, as it wouldn't be practical to create tags or groups "no child, one child, two children..."
Custom tags are very useful as well if you need to let the contacts modify them (eg. via a profile in a registration form).
However, that aren't as convenient as the tags or groups to quickly get a list of members of a category and do something with them.
You can use relationship when the type of relation matter. Eg. makes the difference between the president, the full members, the volunteers...
That's more a special case, and more often than not, you end up creating a group that contains all these contacts, no matter if they are the vice president or associated members (that'd be a smart group)
This is confusing, and there is more than one way of doing it. Ultimately, you can have two experts in civicrm that could use different tools to solve the same problem, and both would be equally right. Our goal is to try focussing or criterias that are defined by the contacts, not by the tools. Ultimately the analysis should depend on the problem, not too much on the tool used to solve the problem.
These are our rules on what to use:
1) Don't over think it, don't make it too complicated, that's not that difficult to transform a group into a tag or into a custom field and the other way around if you realise later that it doesn't work how you started it.
As features of groups, tags, custom fields evolves, one criteria of decision that was right yesterday (I use tags because groups don't allow to do XYZ) isn't going to be correct anymore today, because a new version brought a new feature.
2) Don't create too many categories, there is no point to have 3 categories "green apple", "red apple" and "yellow apple" if you only have 4 apples to group. Create broader groups "apples", or even "fruits", and when you start having too many in one category, split it and manually reassign them to the newly created sub categories.
3) Make it coherent and unambiguous
each of your users should understand and be trained. They should know the meaning and rules of each of these categories. "sport" can mean different things: does it mean "people interested by sport", "people practising sports", "media covering sport" or "organisations organising sport events" ?
Even if each of these interpretation is possibly correct. In your organisation, you should have only one definition, and it should be shared among the users, and enforced.
4)Groups are for what you do with the contacts
If the category is defined by the relationship and type of interaction you have with the contact (sending the newsletter, member of the youth committee, media we want to inform about this type of activity...) , we use groups.
Groups tend to evolve over time, and we might create groups that are short lived, eg. volunteers for our project X. Do delete them once they aren't used anymore, otherwise you will have to many quickly
5) Tags are for what the contact is
When that's a category that describes the contact no matter of your organisation, use tags. For instance, a topic of interest is a tag, No matter what your organisation is, this contact will be interested by knitting and that one by travelling, no matter your organisation.
6) Don't use custom fields for categories
We try to avoid checkbox (or multiple selection) custom attributes to define contacts categories (unless we need them in profiles)
7) Edge cases are edge cases
You will have categories that could be both a tag or a group or a relationship or a custom tag. No matter what you choose, it shouldn't break the coherency of your classification system.
8) Trust your instinct
Overtime, you will develop a gut feeling about what it should be, because you feel it more logical and nice. That's often a good reason enough, but be prepared to alter your judgement and nothing is set in stone.
The Zen of CiviCRM
Or, presented it another way and freely inspired by 'the zen of python'
- Beautiful is better than ugly.
- Explicit is better than implicit.
- Simple is better than complex.
- Complex is better than complicated.
- Special cases aren't special enough to break the rules.
- Although practicality beats purity.
- In the face of ambiguity, refuse the temptation to guess.
- There should be one-- and preferably only one --obvious way to do it.
- Although that way may not be obvious at first and might change tomorrow
- Now is better than never.
- Although never is often better than *right* now.
- If it's empty, don't create it
- That's easier to add later than take out later
- Aim to solve 100% of 20% of the most important cases, not 20% of 100%
So what are your rules and recommendations on group vs. tag vs custom fields vs. ... ?