Aller directement à la fin des métadonnées
Aller au début des métadonnées


Authored by: Jack Aponte of the Welfare Law Center's LINC Project (jack at lincproject dot org)
Additional contributions from Alan Dixon (alan dot g dot dixon at gmail dot com)

CiviCRM provides a variety of features for organizing and extending your contact data. This document provides an overview and some examples to help you determine how best to use these features in your site.


Tags can be assigned to any contact to mark, sort, and organize records. Tags are used to describe a contact - to note something important about them that you want to search and group contacts by. For instance, you could have a "volunteer" tag, which would allow you to a) easily recognize that a contact is a volunteer when you look at their record, and b) bring up a list of everyone who is tagged as a volunteer. You can also use tags to search for certain kinds of people within groups, organizations, etc. For example, you could do a search for all people with the Volunteer tag who are part of the "Speakers Bureau" group, or all volunteers who live within a certain area code, etc.

Other examples of possible tags: donor, potential donor, ally, prospective member, press/media contact, supportive legislator, technical assistance provider, etc.

Tags vs. Groups vs. Custom Fields

I think "tags" is the best way to implement categorization pieces for small/medium projects. "Groups" have these action and permission implications and can be defined in terms of the tags, so they're more useful for short-term projects (e.g, "let's contact all the people with an interest in 'x' and that live in this locality"), as opposed to identifying something essential about a person.

For those of you familiar with languages other than english, it'd be analagous to the difference between say 'estar' and 'ser' in Spanish, one being a (potentially transitory) state and the other a property.

Although the custom fields can also be used for this, they're best used for static information that isn't used in searches or grouping (e.g. historical reference data...).

Conclusion: use tags to migrate custom categorizations from existing systems.

You can review the existing 'tags' for your site, and add others as needed from Administer CiviCRM >> Tags


Groups are similar to Tags in that they give you an easy way to organize and recognize kinds of contacts. However, where tags describe contacts more generally, Groups are used to organize people by the groups of which they are members. This doesn't really mean organizations - we've got separate records for organizations and relationships to track which individuals are a part of them. Instead, this means other, possibly less formal groups of people - for example, your board or steering committee, the TANF campaign, a Speakers Bureau, an affinity group, or a particular working group or committee that's a part of a larger organization.

You can review and add Groups from the Manage Groups menu option.


You can add notes to individual, organization, and household records. Notes are not searchable, but they do show up in the records and are a good way to keep track of various things that you'd like to remember about a contact. Using notes is sometimes a better option than tags, groups, or custom data fields to track things about a contact that you're not likely to want to track about many contacts in your database.

For example, if you'd like to remember that you met Amanda at a certain conference, but don't need to keep track of a lot of other people who went to that conference, you can just make a note of it in her record, instead of creating a whole new tag or group for conference goers.


Relationships are used to track connections between different records. You can create all sorts of relationships between the three different kinds of records (individuals, organizations, and households.) Each relationship actually consists of two parts, which describe each side of the relationship between Contact A and Contact B - there's an A to B relationship, and a B to A relationship. At times, the A to B relationship is different in wording from the B to A relationship.

You create a relationship between two contacts, Contact A and Contact B, by going into Contact A's record and adding the relationship there. You only have to create the relationship within one contact's record; when you create the relationship for Contact A, the other side of the relationship is automatically created for Contact B, and the relationship will appear in both contacts' records.

Here's some examples:

Parent/Child Relationship between two Individual records:
A to B: Parent of
B to A: Child of
So, if we create a relationship showing that Esperanza (Contact A) is the "parent of" Jack (Contact B), Jack will appear as the "child of" Esperanza.

Partner Organization Relationship between two Organization records:
A to B: Partner Organization of
B to A: Partner Organization of
If we create a relationship showing that Community Organization for Justice (Contact A) is a "partner organization of" Activists for Justice (Contact B), Activists for Justice will appear as a "partner organization of" Community Organization for Justice.

Member Relationship between an Individual record and an Organization record:
A to B: Member of
B to A: Members include
If we create a relationship showing that Jack is a "member of" Community Organization for Justice, then Community Organization for Justice will show that its "members include" Jack.

You can review the existing 'relationship types' for your site, and add others as needed from Administer CiviCRM >> Relationship Types

Custom Data Fields

CiviCRM comes with a lot of fields built in to track different kinds of information. However, it's also likely that there will be other sorts of information that you want to track about each of your contacts and that can't be handled well with Groups or Tags. For this, we can create custom data fields.

You can add custom data fields to handle all sorts of information not covered by standard CiviCRM fields. However, you should keep in mind that too many custom fields will just add clutter to your database and won't help you effectively track information about your contacts. So, you should limit custom fields to things that you know you'll want to consistently track about many people in your database. Before you create custom fields, think about whether you can better track this info using notes, tags, groups, or already existing fields.

Add custom data fields from Administer CiviCRM >> Custom Data

  • Aucun