In most cases, the three main contact types we just described are sufficient for organizational needs. When you need to collect and store different information about subgroups within these types or define relationships specific to a subgroup, you may consider further segmenting your record types into contact subtypes. Each subtype inherits its basic "entity identity" from one of the three main types, but otherwise, it can be treated as unique.

Contact subtypes are created and managed through: Administer | Option Lists | Contact Types. From this screen, as seen in the following screenshot, you can rename the existing types (including the three primary types), create new types, and assign icons to each type in order to help visually distinguish them while reviewing the records.

It is important to give a careful thought as to how you work with different types of contacts when you configure and build out your CiviCRM implementation. Contact types may be viewed as the highest level of categorization in your system and the choices you make will have implications throughout the rest of the system.

Consider the following as you plan your contact types:

While we are discussing contact types, there is another important consideration to think through, particularly if you have a complex organization with multiple administrative users who will be working with CiviCRM.

As we will see shortly, a large part of working with CiviCRM involves connecting related records with the contact record. For example, you may track phone calls and meetings held with an individual, donations contributed by a business, membership from a household, or open a case for any of these contacts. Very often, there are connections built between related contacts and in each instance, you must decide where the contribution, membership, or other records should be attached.

In most cases, it is very clear where the associated record should be attached. However, where there is potential for confusion and ambiguity, you will want to establish clear policies and procedures to help staff determine the proper location for the data.

Consider the following questions:

Regardless of how you resolve those potential areas of confusion, it is important to strive for consistency. How you enter your data will have a direct impact on what you are able to pull from the system.

The contact details pane contains basic information about an entity, including the following:

As we'll see in Chapter 6, Communicating Better, CiviCRM allows you to create sets of custom fields and indicate whether they should be displayed inline or in their own tab on the Contact form. If some custom inline fields have been defined for all contacts or the specific contact type you are editing, these fields will appear directly under the contact details pane.

Similar to communication options, you may create multiple address sets, categorize them (home, work, and so on), and flag one of them as the primary address. There are a few important things to note:

We can see the Address pane in the following screenshot:

Now that you have your contact record in place and have recorded all the various ways you might be communicating with them, CiviCRM provides tools for further classifying (and limiting) your communication methods. These preferences are broken into four areas:

Individual contact records will have a Demographics pane where the Gender, Date of birth, and Deceased date can be recorded. When conducting a search to export contacts for a mailing list, you can exclude contacts of people who are deceased in order to ensure that they don't receive the mailing.

Tags provide a hierarchal categorization mechanism across all contact types. They are a categorization mechanism—you use tags to record information about the nature of your contacts, such as the type of services they provide, skills they have, areas of interest, or other such information. They can be hierarchal; you can build out your tag structure with categories and subcategories. When viewing and selecting tags from the contact summary edit screen, they appear in a simple list with indentations to visualize the hierarchy. Viewing them in the dedicated tab displays a similar structure, but uses an expandable/collapsible tree tool to better reveal the hierarchy and allows you to quickly navigate through the structure.

Tags are applied across all the contact types, which means that you cannot create sets of tags specific to a single contact type (for example, organizations). Keep this in mind, as you may want to consider other categorization tools such as groups or custom fields, if your available options need to be contact type or subtype-specific. Tags can also be created and applied to contacts, activities, and cases; at the time the tag is created, you choose how the tag will be used.

In addition to the hierarchal tagging structure, CiviCRM provides tools for creating freeform tagsets. This tag feature differs from the hierarchal tree in several ways, as follows:

As indicated earlier, before using hierarchal tags with your records, you must define them in the system: Administer | Option Lists | Tags (Categories). Use the New Tag button to create new tags, and the Edit/Delete links to manage your existing tags. Note that while the administrative page lists all the tags alphabetically, the Parent ID column will help you track the hierarchy of the structure.

The Tags tab in the contact record presents the most user-friendly interface for tag selection. While you may optionally manage a contact's tags using the Contact Edit screen, the interface is a bit more limiting because of the other elements on the page. This is especially true if you have a long list of hierarchal tags in your system. The Tags tab represents the hierarchal form in a more visually appealing way and allows you to dynamically expand/collapse the parent tags to view the child options.

To help you easily get a glimpse of how a contact has been tagged, CiviCRM provides a comma-separated list of all the selected tags on the Summary screen, as shown in the following screenshot:

Groups are simply a collection of records that may be defined statically or dynamically. Static groups are sometimes referred to as regular groups or simply groups, and dynamic criteria-based groups are called smart groups.

Think of a static group as a container in which you manually place your records. There are no specific criteria by which people become part of a static group they are added or removed based on their or your preference. For example, you might create a "Board of Directors" group and add the nine contacts in your system, who currently are members of the group. Another example of a common use for static groups is opt-in mailing lists. As people visit your website, you might provide the option of signing up to receive a periodic e-mail newsletter. The signup form (and unsubscribe tools) will empower visitors to add or remove themselves from your newsletter group.

In contrast, smart groups are generated based on the criteria you have defined, and thus are dynamic in nature. For example, you may have a group that retrieves all contacts in a certain area where the criteria you've defined is a specific city, state, or zip code proximity range. Smart groups store the criteria and not the static list of contacts at a given point in time, and thus serve as a saved query in your database. If you return at a later date to view the contacts in a smart group, CiviCRM will pull a fresh list of contacts that meet the defined criteria.

Although you typically will create a static group and then add your records to this container, smart groups are generated from search results. After running a search for contacts, you may take certain actions on the results, including saving them to a smart group that can easily and quickly be retrieved at a later date. While retrieving a saved smart group later, you are given an opportunity to adjust the criteria and update the settings. Smart groups also have the flexibility to manually add and remove contacts. Hence, those who may not fit the criteria can be added and others who do can be excluded.

Creating groups

Groups are created and managed through Contacts | Manage Groups. Note that you only create static groups through this page, but may manage both static groups and smart groups. Since smart groups are criteria-based, they may only be created from search results.

When creating a new static group or editing an existing group, you are presented with the following form:

In addition to the group Name, Description, and Group Type options, you'll notice two additional fields we have not yet discussed:

• Visibility: This controls whether only administrators can use the group or whether it may be available for public signup forms. For example, if you are using this group for opt-in mailing list signup, you will want to designate it as Public Pages visibility. You may then add the Groups field to a profile form and allow people to add themselves to the group. It also determines if the mailing list groups appear to non-administrative users on the general mailing list subscription form at http://yourdomain.org/civicrm/mailing/subscribe?reset=1 (for Drupal), or http://yourdomain.org/index.php?option=com_civicrm&task=civicrm/mailing/subscribe&reset=1 (for Joomla!). In general, your groups will typically be assigned User and User Admin Only, unless you want to make them publicly available.

• Add Parent: Groups may be hierarchal, which means you may create a parent group with a series of subgroups underneath it. Searching for group members in the parent group will include all members of any child groups.

Note

FPAGM initially creates a Board of Directors static group and a Current Members smart group that retrieves contacts across all three membership categories with a status of new, current, or grace. This allows them to easily access a running list of all current members.

In addition, they create a parent group called Food Pantry Members with child groups for each category based on the tag selections. The child groups are smart groups generated from search results, while the parent group serves as a simple container for the three subgroups, as we see in the following screenshot.

The potential capabilities for groups, and in particular, the dynamic nature of smart groups, are virtually endless. With some creativity and planning, you can capture just about any subset of records. For example, the ability to define searches and smart groups based on existing group membership allows you build to complex collections of records using disparate and unrelated record subsets. Consider the following example in which FPAGM wishes to assemble a targeted mailing to potential donors:

• Create a smart group for current supporting members
• Create a smart group for past contributors, who have made a donation larger than $500 sometime over the last three years
• Create and maintain a static group called Donor Outreach, in which they manually maintain a list of organizations they are courting for high-end donations
• Create a smart group that collects members of the three groups above, plus the existing Board of Directors group, and is entitled Potential Major Donors

This final smart group, which combines records from three very different groups (one based on membership, one based on past contributions, and two that are static groups), now serves as their master list for targeted major donor solicitation.

Relationships are used to connect two records to each other. When defining relationships you may limit the types of contacts available to each side of the connection; for example, an employer/employee relationship would only exist between an organization and an individual. Other relationships may be more flexible with no contact type restrictions.

Relationships have labels to help distinguish the nature of the connection from each side of the equation. For example, John Smith may be an Employee of ACME Convenient Store and ACME Convenient Store would be the Employer of John Smith. Some relationships do not distinguish differences in each side of the connection, such as Spouse of.

The relationships tab in the contact record lists all the active (current) and inactive relationships. An inactive relationship may occur if an existing relationship is manually disabled (for example, if an employee of a company is on a leave of absence or laid off, and you manually mark the relationship as disabled), or if an end date is recorded for the relationship (for example, you create a board member relationship and record the start and end date based on a two-year term). By default, relationships are assumed to have no set end date.

Entering end dates or disabling relationships rather than deleting them provides a useful way of tracking the contact's history of involvement in various capacities. For example, it may be useful to see the employment history of an individual by reviewing current and inactive Employee of relationships. You might use this information to identify influencers for major donors or to find social networks that could facilitate potential strategic partnerships.

Before working with relationships in a contact record, you should review the existing relationships types that are created when CiviCRM is first set up and determine if there are any other types you will need to create.

To do this, go to Administer | Option Lists | Relationship Types.

This table lists relationship labels for each direction (from A to B and B to A), and whether there are restrictions on the types of contacts allowed for each side of the connection.

If this structure is confusing, use the following statements when reviewing and creating relationships, replacing A and B with your labels:

It may also be useful to review a very clear existing relationship type, such as employer/employee, to understand how the label text is used. Using the preceding statements with the employer/employee relationship, we would see:

Note that if you select one of the primary contact types (Individual/Organization/Household) when creating a relationship, the relationship will be available to all associated subtypes. However, if you select a subtype for one side of the relationship, it will only be available to that specific subtype.

Once you have your relationship types configured, you may begin to build connections between contacts. Navigate to the contact record's Relationship tab to view, create, and edit their connections.

The relationship creation process consists of two steps, namely, selecting the related record based on the type chosen, and filling out the relationship details.

In addition to the basic start/end dates, description, and notes, there is a basic permissioning function handled through relationships. Using the two options presented, you can allow either side of the relationship to view and modify the other side's contact details.

Where does this come into play? CiviCRM has a special contact summary page called the Contact Dashboard, which can be exposed to website users. The dashboard provides a snapshot of the user's interactions with your organization, including membership history, event registrations, contribution history, and group membership. In addition, the dashboard may contain a list of relationships defined for the individual and if permissioned through this form, it will allow the logged in user to edit details for the related record(s).

One common use case for this functionality is when you want certain administrative contacts (individuals) to have the ability to edit their employer's records. Since organizations don't visit websites (people do), you would need to allow certain individuals the permission to edit the organization record. Other examples include allowing parents to edit their children's records, teachers to edit their students' records, or household members to edit the household record.