This documentation refers to an older version of CiviCRM (3.4 / 4.0). View latest version.

Comparaison des versions

Ancienne version 3

changes.mady.by.user xavier dutoit

Sauvegardée le

comparé à

Nouvelle version Actuel

changes.mady.by.user xavier dutoit

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • Formatting was changed.
Commentaire: Migrated to Confluence 4.0
Return to Tags,   Return to Groups,   Return to Custom Fields

Tags vs. Groups vs. Custom Fields

There are no hard and fast rules about when to use Tags, Groups and Custom Fields. We had a long discussion about it, with the main conclusion seemingly to be that they are as many rules as installations. Using the guidelines and examples below, you must decide for each piece of data which of the three is best suited to your needs. Consider not only the type of data, but what you will use the data for when determining which one is the best fit.

Tags

Tags are best used for high-level categorization of the contact records in your database.

Limitations

Benefits

  • You can only assign TAGS to contact records (you can not tag activities, events, etc.)
  • You can not create TAGS for use with specific types of contacts (i.e. you can't create tags that are ONLY for use with Individual contacts)
  • When you export tags, all tags assigned to a record are exported in a single "cell" as a list (e.g. "Teacher, Volunteer")
  • Tags allow multiple selections - so they may not be appropriate for mutually exclusive characteristics (e.g. "Democrat", "Republican", "Green Party")
  • You cannot selectively hide or permission TAGS on built-in or Profile create and edit forms (you get ALL tags ALL THE TIME on edit forms)
  • Easy to setup and use
  • Easy to search by tags (can use either Basic or Advanced Search)
  • Easy to combine with other properties (like residence state/province) to create Smart Groups

Groups

Groups are used to segment the contacts in your database - most often for controlling access to data and facilitating specific organization tasks. Groups may be created to serve the needs of short-term projects and may also represent persistent segments of your constituent/contact base. There are two kinds of Groups - Smart Groups and Regular Groups.

Smart Groups allow you to dynamically assign contacts to a group based on one or more characteristics and/or activities of those contacts. For example, you can create a Smart Group for "Recent Contributors from California" - which combines the "activity" of making a contribution during the current year and the "characteristic" of having an address in California. When new contacts in California make a contribution, they automatically appear in this group.

Regular or 'static' Groups allow you to explicitly place contacts in group independent of their characteristics. New contacts are NOT added simply based on some change in their data. For example, you would need to explicitly assign your Board Members to a "Board of Directors" group. You can then use this group to easily send board-related emails to this group. You may also want to restrict permissions to view and/or edit the contacts in this group.

Limitations

Benefits

  • All existing GROUPS are listed under Manage Groups and
    in the search forms. This may cause group "overload" if
    your organization winds up with "too many" groups.
    Groups used for short-term projects should be "purged" when they're no longer needed
  • When exporting contact records, all the GROUPS a contact
    belongs to are exported as a single comma-separate list
    (e.g. "Administrators,Newsletter Subscribers")
  • GROUPS are the most flexible way of segmenting your contacts for a wide variety of purposes.
  • GROUPS facilitate recurring tasks like sending an enewsletter, printing mailing labels, etc.
  • GROUPS allow you to restrict access to "special" sets of contacts
  • GROUPS support both administrative and end-user "subscribe" and "unsubscribe" actions - and a history of these actions is kept in the system
  • Visibility settings allow you to decide which groups are shown to end-users on Profile forms (i.e. some groups can be "private")
  • you can create Smart Groups that combine members of Group A + Group B
Tip
titleGroups required for civiMail functionality

CiviMail uses Groups to determine the recipients of bulk emails. In order to send to a group of constituents, you must first create a group (standard or Smart Group) and assign all desired recipients to that group, i.e., Enewsletter Subscribers or Annual Donors. Of course Smart Groups can be built from custom data or a combination of custom data and groups.

Custom Fields

CUSTOM FIELDS provide a flexible means of collecting and storing many types of data about your contacts, contributions, activities, members, event participants and more. Custom field values are searchable in Advanced Search and in the search screens for each component. This means you can easily do ad-hoc searches based on one or more custom fields ("Find all Individual contacts whose Profession is 'Nurse' and who works in a 'Private Hospital').

Limitations

Benefits

  • Changes in CUSTOM FIELD values over time are not tracked (unlike a contact's "subscription history" for a GROUP)
  • You must use Advanced Search to find contacts based on CUSTOM FIELD values
  • CUSTOM FIELDS can store almost any type data including Text, Dates, Numbers, Attached Files (e.g. a resume), Photos, etc.
  • CUSTOM FIELDS data can be collected from end-users via Profile forms - and can include detailed inline help text
  • CUSTOM FIELDS can be configured as simple text input fields, mutually exclusive multiple choice fields (drop-down or radio button style), inclusive multiple choices (checkbox) fields, yes/no fields, date selectors and more.
  • Access to CUSTOM FIELD data can be restricted
Tip

Read more about design and limitations on custom data groups here.

Examples

Volet

Education organization example

An organization with a focus on educators wanted to collect information about their members, K-12 teachers. They wanted to collect data on the teacher's primary subject areas (Social Studies, Science, Music, etc.), their interest in the organization's programs (training events, volunteering, etc.) and the teacher's enewsletter preferences (Mathmatics Studies, book club, etc.).

Based on their needs, they chose to use:

  • GROUPS to collect information on enewsletter subscribers. They use these groups to mail out the newsletters, and the GROUP feature allows the teachers to subscribe and unsubscribe to the mailing.
  • CUSTOM DATA FIELDS to collect information on the primary subject areas. When the organization needs to gather members for a subject-specific project, they can find and communicate with "Social Studies" teachers using Advanced Search. They can even create a Smart Group of "Social Studies Teachers" for the duration of the project.
  • TAGS to record interest in the main program areas (High-level categorization).
Volet

Community Health Center organization example

An organization with a focus on community health centers wanted to collect information about one group of constituents, health center workers. They wanted to collect data enewsletter preferences (program news, advocacy information, etc.), the type of organization they work for (government, hospital/health center, etc.) and their role in the organization (outreach worker, tech staff, etc.).

They chose which tool to use based on their needs, which included sending out enewsletters to subscribers, keeping informational data on type of organization and on organizational role.

Based on their needs, they chose to use:

  • GROUPS to collect information on enewsletter subscribers.
  • CUSTOM DATA FIELDS to collect information on the organization type and staff role. These fields allow them to aggregate statistics on their constituents on these dimensions and track changes. They also can use them for communicating about specific campaigns which are particularly relevant to "Nurses" or "Social Workers" (for example).
  • They chose not to use TAGS because their database contains a mix of Individuals and Organizations - and there was no logical use of high-level categorization across these types of records.