Categorise your contacts: group, tags or custom fields ?

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

Groups

Pro: A group in CiviCRM can be either a mailing group, or used to define access rights. Con: 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.

Tags

Pro: good hierarchy (since 2.2) Well visible in the summary page Cons: 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

Custom fields

Pro: can have more that a simple "belong/doesn't belong" easier to set the layout Con: 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.

Relationships

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)

Our rules

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

Comments

I would like to see more emphasis placed on membership and access levels so events can be restricted to certain memberships. This is how my client categorises their contacts. As a result I'm reserving groups for newsletters etc and perhaps defining access to administer the system.

Forgot the civimember, I'm going to update the article with your input. As I see it, that's mostly like relationship (you need to add smartgroups on it)

Xavier - thanks for sharing your thoughts and experiences on this topic. I suspect it will be quite helpful to folks. What do you think about including a version of the above on the wiki (maybe after you tweak it with any other feedback over the coming days). I think it would fit nicely as a child of / linked from the Categorize page. Also, I think we could add a link to this info from Getting Starting » Basic Terminology.

Hi,

I'm still expecting to have more discussions around and see how people do use the various categories stuff to see if a common best practice emerge.

X+

Hi,

We have an opposite approach: for me tag is more permanent than a group. Probably because of the features bound to a group: you can do emailing or add "automatically" to a group (via a profile), something you can't with a tag.

X+

too full on to comment seriously now, but our usage has been quite different to x's and would be worth considering the different approaches we are talking - so good thread

pete davis : [i]fuzion[/i] : connect + campaign + communicate

Hi,

The issue I see is that they are too many ways of doing the same thing. If we could find one common strategy, it would allow to make evolve each categorisation tool to specialise on what we agreed it should do, instead of facing plenty of "one size fits all" tools.

No matter what, each organisation needs a coherent strategy as to what tool to use for what categorisation need, right now, I think that's more a matter of our respective habits, but might be good underlying reasons so one is better than the others.

(Not sure it's possible at all, but worthwhile as a goal).

i see others have already made the case for greater reliance on Groups. Main reason we rely largely on groups for our clients is that Mailing Lists are dependent on them. So an organsition that has 200 categories for 'media releases' that need to be distributed have zillions of Mailing Lists.

I would tend to see Groups and Tags as equally permanent, but use Tags for more generic groups. But rarely see them being used as such. When it comes down to it, we need to be able to communicate with them, usually en masse, so get driven to use Groups.

That said, we actually manage most of that data as Custom Fields and then build it up in to Mailing Lists (ie Groups).

It would be hugely helpful to be able to determine which Groups are visible to people based on their (small 'r') roles. Maybe possible in 2.2

We do use Tags to ensure that some info is delivered on the Summary page - ironically we need that to be Smart Tags, so end up with out of date info that needs to be manually updated occassionally!

pete davis : fuzion : connect + campaign + communicate

As far as I'm concerned, the redundancy of categorization concepts is a big problem with CiviCRM, causing confusion to the end users and increasing the complexity of the API.

To me, Tags are just Groups that you can't do anything with. I never use them. Is there significant performance advantage to tags? My clients don't have super huge databases. My largest right now is 40k contacts, and they use Civi almost exclusively for CiviMailing, so tags aren't an option.

I'd be in favor of removing Tags entirely, especially now that we have group hierarchy for sorting purposes.

The similarities/differences between CiviMemberships and Relationships is a similar problem. These two objects should be merged also.

Maybe all 4 could be one chain of inheritance.

class TAG
property $contact
property $entity
property $entity_type (Category OR Contact)
property $parent_tag
class GROUP extends TAG
property $is_mailing_list?
property $is_ACL?
method Set_Add_Datestamp()
method Set_Removal_Datestamp()
class SMART_GROUP extends GROUP
property $binding_object_type (Custom field, Relationship, Membership, Event)
property $binding_object_instance (e.g. custom_field_id = 99)
property $binding_criteria (e.g., $Membership->status = expired)
method Update_on_custom_value_change()
class RELATIONSHIP extends GROUP
property $relationship_type
class MEMBERSHIP extends RELATIONSHIP
property $expiration_date
property $member_fee
property etc...
$relationship_type = 'Member'

Now all Memberships can automatically have a corresponding mailing list, and any time we add a feature to Tags, we have it available for Memberships too. And we can have one set of api functions which are agnostic about the particular features available to the particular categorization: categorization_create(), categorization_get(), hook_on_categorization_update(). Now I can get a list of all the categorizations that grant a particular ACL permission. I can set a removal date for all categorizations at once, without knowing what they are. (e.g., a contact is deceased so they're no longer registered for any events or recieivng any mailings; an employee is terminated, so they're no longer on any committees, whether or not those committees have ACLs, positions ($relationship_type), or $expiration_dates.)

You want a Members-only mailing list? It's built in. You want a mailing list for all past and present members? That's a smart group bound to a particular membership without any criteria. You want to grant access permissions to Members? ACL is included.

The implementer should be able to choose at each level whether or not to expose the class in the UI. No need to confuse the end users with Tags, if they always need access control for each category. Wise quote from xavier: "There should be one-- and preferably only one --obvious way to do it."

I guess I don't really expect to see this kind of change before 3.0, but it's nice to dream...

Matt

--
Drupal/CiviCRM micro-blogging http://twitter.com/matt2000
Ninjitsu Web Development http://www.ninjitsuweb.com/
Portfolio: http://www.NinjitsuWeb.com/portfolio

BTW, this comes mostly from my work on the Drupal Role sync modules. It strikes me as rather absurd that we need separate modules to sync between Roles<->Groups and Roles<->Memberships. If a Membership was nothing different than a Group (for which you can purchase your place, for example), it would be one module. Better DX and UX.

Hi,

Good point about the hierarchy, it gave me a new perspective.

As for the case you describe, if you only use it for mailing, by all means don't use tags indeed.
Our usage is different, with a lot of advocacy: We don't have a huge amount of contacts, but that's important to know much about each of them. Say you have parliament member, that's important to know that one is interested in health, fishery, chemical industry and education. We have dozen and dozen of topics of interests, that aren't directly used (as a group would for a mailing for instance). That's more soft data, but when you want to send invitation to an art event about fish, that's handy to select the parliament members that are tagged art or fishery.

X+

In the section: Custom fields: con: it says:

"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"

but it should say:

if you need to be able to enter a date or a number (eg number of children), custom fields are for you, as it wouldn't be practical to create tags