Dashboard > CiviCRM Documentation > ... > Cookbooks > Organizing Your Data
Organizing Your Data Log In | Sign Up   View a printable version of the current page.

 Contents
  Documentation Home

HOW TO USE TAGS, GROUPS, NOTES, RELATIONSHIPS & CUSTOM FIELDS TO ORGANIZE YOUR DATA IN CIVICRM

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

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

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.

Notes

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

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


Added by David Greenberg , last edited by David Greenberg on Sep 05, 2007  (view change)
Labels: 
(None)

Recently Updated  |  Documentation Credits

Update: CiviCRM 1.3 allows exporting of Custom Data Fields.

To me there is some confusion about the difference between a GROUP and an ORGANIZATION. It is sort of wierd yet interesting to me that a group is intended to either act as a

SUB-GROUP heirarchically under an organization (say if you use the CivicCRM primarily internally to modulate and keep track of different committees' and their work who is on them etc. (A good example of an organization that might function like this would be a state chapter or local group of the Sierra Club where they have a Conservation Committee, an Executive Committee, a Transportation Committee etc. and everyone listed in the CivicCRM is a member of the organization automatically)

OR

in an ORGANIZATION sense (see an example of this where Janet is a member of more than one group = Antartic, Penguin & US Scientists)

But then if this is the case and Groups are Organizations, then why do you have the category Organizations and why can't people be members of them? Perhaps you need other designations besides Households that are under Organizations -where a person can be a member of a team or Committee??

I like the fact that Groups can also be LARGER than Organizations heirarchically also - ie. say when different Organizations  collaborate into "Working Groups" or "Collaborations" and work as Partner Organizations as you describe in a relationship above. Maybe  I am misunderstanding what a group is entirely. I guess I just want to see clearer definition of how these contact category types are structured and what then they can be used for so that I can have both types of groups... (Yes I am a cake and eat it too kind of person)

The way that I was/am envisioning being able to use CivicCRM may be more complex than the regular organization.  

Again, I'm new, please forgive if this is the wrong place for this kind of comment. I am still trying to figure out CivicCRM and how to use it. If you care to correct any of my thinking please do so by sending an email. Thanks! Laura

Hi Laura,
In general, the Organization data model is oriented towards more formal entities that (may) have a physical location and legal structure. You can use relationships to describe how a person is related to an Organization (employee of, volunteer for, team leader of...).

Groups are more simply collections of contact records (either Individuals and/or Orgs and/or Households). Both concepts support hierarchies - as you can create Organizations that are chapters of parent Organizations by creating a "Chapter of" relationship type. For groups, you can create smart groups that are contain other group(s) or are a subset (for example, members of the Newsletter Subscriber Group who live in Oregon).

This is a great conversation to have on our mailing list - as you are likely to get a variety of perspectives from current users. I would recommend repost your comments to the crm-dev list:

http://lists.objectledge.net/mailman/listinfo/crm-dev

Regards,
Dave Greenberg, CiviCRM team

Non

I am new to CiviCRM and have been experimenting with it for just a few days.

To start off with, I just need to add a few Organizations to my database, and then enter a number of Individuals that work at each Organization. Ok, so I use a Relationship to express that these 10 Individuals are employees of a particular organization. But it looks like I have to enter address information for each of the Individuals - isn't there a way for each Individual to "inherit" the address of the Organization they work for? So that if the Organization changes address I don't have to then change all the Individual records?

When I generate a search result page, I would then want the Organization's address on each line, so that when I generate Mailing Labels they actually get populated with a valid address.

Aside from that I seem to be having some trouble with Profiles. Each Individual also has a Home address that is not the Primary. I want to set up a Profile to be used for search results that will display their home address fields. But when I use the field selector it seems to always pull fields from the Primary  - how can I express that I want something else?

In any case, I created a Profile with a few fields. Then I went to Advanced Search, entered some criteria, and selected my new Profile from the Search Views pulldown. It generated a result page just the way I wanted. So then I created a Smart Group from the "more actions"  pulldown, and named it. But now when I go to that group via the Manage Group page it has the default view, NOT my new Profile view. Isn't the Smart Group supposed to retain all the criteria I entered??

Lastly, I would like to create a link to this Smart Group from one of my Drupal menus that I have in a block on the left side of my page. When I create a menu item I enter something like "civicrm/group/search?reset=1&force=1&context=smog&gid=4" as the URL, Drupal ends up encoding the question mark and ampersands, so the result is I don't get to the proper page. Anyone know how to make Drupal do the right thing with the URL?

Thanks!

-Bob

Hi --

 I have been trying to figure out how to create a smart group. I thought there might be some info here but I didn't see it. Where should I look for information like that?

Hi Eric,
Info on creating a smart group is here: Smart Groups

Going forward, the search on this wiki is pretty decent - and if you don't find what you're looking for or need more help/ideas - the CiviCRM community mailing list is a great resource:

http://lists.objectledge.net/mailman/listinfo/crm-dev

Regards,
Dave Greenberg, CiviCRM team

I'm planning a large and high-traffic site, and I'm concerned about overwhelming the server with lots of queries. My concern is heightened by this horror story by techsoldaten:
http://groups.drupal.org/node/811

I'm not planning on a Contact file with 2.4 million records, but it could reach 50,000 pretty quickly and 500,000 over time.

It would therefore be most helpful if this page included a description of the operational differences between these data types and their implications for server performance.

1) Are all fields (including custom fields) searchable? Can they all be components of definitions of relationships and smart groups?

2) Do any of these data types result in the creation of MySQL indexes? If so, how much do indexes slow record insertions and updates? Does this argue for limiting the number of indexes?

Obviously most of these data types do not create indexes, so any queries involving these fields will be much slower, and will slow down the server while the search is conducted. Does this argue for increasing the number of indexes?

Any advice along these lines would be extremely helpful in the planning stages, to avoid frustration when the site grows.

When you create a new custom field and save it you go all the way back out the the administer civicrm screen. It would be better to go right back to the custom group screen which would eliminate many clicks as you are working on custom data.

Hi Elin,
I tried to recreate this behavior on both the Drupal and Joomla 1.4 demos. When I add a custom field and save - it takes me back to the listing of fields for the custom group (not back to the Administer CiviCRM screen). If you can recreate - please post this as a bug in our issue tracker with the exact steps to recreate. Thx!
dave

Powered by a free Atlassian Confluence Open Source Project License granted to CiviCRM . Evaluate Confluence today.
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators