Simply put, a contact is any entity you interact with. It may be people, businesses, government institutions, households, organization chapters, regional districts, or anyone else you are collecting data for in your system.
Since all contact entities are not the same and the nature of how you interact with them will be different from one to the other, CiviCRM segments contacts into three main types, with the option of further segmenting them into subtypes:
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.
The Food Pantry Association of Greater Metropolis (FPAGM) provides services and support for food pantries within the city of Metropolis and the surrounding area. On a daily basis, they interact with 30 to 40 food pantries that are members of the organization. In addition, they interact with restaurants, grocery stores, and convenience stores that donate food from their surplus for distribution to the food pantries.
It is clear that the food pantries and businesses donating food are distinctly different entities. The nature of the data they collect, interaction through mail and e-mail, and types of reports that will be run will be different, depending on whether the organization is a pantry or food supplier. Consequently, FPAGM has decided to create two contact subtypes under the main organization type.
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:
You assign contact subtypes when you create contact records. If an existing contact does not have a subtype selected, you may specify one when editing. However, if you've selected a subtype and stored any custom data associated with that type, you will no longer be able to change the subtype (unless all custom field sets for that subtype have been permanently deleted). For example, FPAGM creates a custom data field to track the daily average of the number of clients a food pantry services. This field is attached to the Food Pantry subtype, as it is only relevant to those contacts. If we create a new organization record, assign the Food Pantry subtype to it, and save the organization contact, the record is now locked on that subtype; we cannot decide to change the record to the Food Supplier subtype at a later date. This system behavior ensures protection against unintended data loss or orphaned data. If at a later time you decide to completely delete the custom data fields associated with the subtype, you will once again be able to reassign a contact to a different subtype. Basically, CiviCRM locks the subtype in order to prevent data loss—if there is no subtype-specific data stored for a record, you can change the value without risk.
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.
John Smith, the proprietor of ACME Convenient Store, calls FPAGM to arrange the donation of 50 lbs. of bread for distribution to food pantries. FPAGM staff will track this as an in-kind donation in CiviCRM. The question asked is should the contribution be recorded with John Smith (after all, he is the owner and primary contact), or with ACME Convenient Store?
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.
Once you've defined your contact subtypes (if any) and thought through the policies you will put in place for the staff, take the time to manually create a few records with real data to test your structure and policies. This may help you identify and correct any unanticipated consequences of your configurations.
Let's get into a contact record and begin to see how this idea of a contact with related records takes shape in CiviCRM. If this is your first time in CiviCRM, place your cursor in the search box to the left of the CiviCRM menu bar, as seen in the following screenshot, and then click on Enter to view all the records:
At a minimum, you should see one record corresponding to your website user account (you may also have seen that record in the left sidebar recent items list). Enter this record, or any other one, to view the contact details.
As you can see, the contact record is displayed through a series of tabs corresponding to the different types of data you may be collecting.
The tabs displayed in a contact record depend on configuration settings in two places: Enable Components (Administer | Configure | Global Settings | Enable CiviCRM Components) and Site Preferences (Administer | Configure | Global Settings | Site Preferences). If you do not see an expected tab, make sure that the component is enabled, and that you have indicated that it should be viewable on the contact record page.
We will not discuss all of the available tabs at this point, but only cover those that are directly related to the contact record itself, including communication tracking, relationships/connections with other records, and core categorization tools.
The default summary tab is perhaps the most important tab, as it tracks the contact name, communication details and preferences, addresses, and demographics (if it is an individual contact type). Click on the Edit button at the top of the tab to view all the available fields for your contact. You will notice that the edit screen is broken into grouped panes of fields corresponding to the different types of information you are collecting.
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:
When you first install CiviCRM, the address pane contains all of the available fields, including some you may not want to display. Visit Administer | Configure | Global Settings | Address Settings to turn off elements in this pane. For example, you may only want to track two address lines, and so you would disable Additional Address 2. Likewise, it is unlikely that you would need to manually edit the latitude and longitude values for records, as that will typically be handled automatically if you have enabled address geocoding for your site.
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:
When in the contact summary view, you will notice a Delete button above and to the right of the tabbed interface. CiviCRM has a contact trash function; when you click on this button to delete a contact, it does not completely remove it, or any related records from the system, but rather marks it as trashed. Trashed records can be searched for using the Advanced Search tool; an option to Search in Trash (deleted contacts) is found toward the bottom of the Basic Criteria pane. After searching for trashed contacts, you can delete it permanently or restore it.
This functionality is a powerful way to protect your data against inadvertent deletion. However, as with any safety net, you should not over-rely on it. Never trash a record with the intent of later restoring it. Trashed records should be viewed as fully deleted (and will appear as if they were actually deleted by the system when searches and reports are generated).
Note that you may disable the trash function on your system through Administer | Configure | Global Settings | Miscellaneous.
You may have noticed that we skipped the Tags and Groups pane found at the bottom of the contact summary edit screen. These records are also found in their own dedicated tabs on the View Contact screen, and so we'll take a look at the functionality they provide in the context of their own tabs.
The Tags and Groups tab provides two powerful mechanisms for categorizing and organizing your contacts. However, it is not always readily apparent which of the two mechanisms is best suited for a specific need.
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.
FPAGM uses tags to track the types of services and nature of the contact entity. This includes several subcategories to further refine the information gathered about a contact. They define a single "keywords" tagset to further classify records beyond the hierarchal 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.
It is great that you have tools to collect and organize your contacts into groups, but how will you actually use them in the system? Here are some of the most common uses for 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:
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.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:
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.
Contacts that are a part of a group are called members of the group. Don't confuse this group membership with your organization's membership functions; those are handled elsewhere. Group membership indicates if the contact has been added to or removed from a given group.
You may add or remove contacts to a static group through the contact summary edit form, or on the contact's Groups tab. CiviCRM will timestamp the date and time when the record was added or removed. While smart groups are primarily defined by search criteria, you do have the option of overriding the criteria and manually adding or removing members using these tools. Note that the contact's Groups tab will only display the static group memberships. The contact may be part of several smart groups by virtue of meeting the search criteria, but those will not be listed on this tab.
Once you've created your static group and added contacts to it, you will want to access it and review the list of members. We do this through the Contacts | Manage Groups screen. Find your group and click on Members to view the list of contacts.
As noted earlier, there are other ways to automatically add contacts to groups, such as through profile signup forms or during the import process. In addition, you may add or remove contacts from groups after conducting a search using the actions drop-down options.
We've already mentioned relationships several times when discussing grouping individuals with a household, and recording the current employer for an individual. We now want to explore the full breadth of options and uses for relationships.
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.
Two types of relationships may be constructed from an individual record's summary edit screen:
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.
Up to this point, we have primarily focused on recording data that describes our contact records. However, the power of a CRM is fully realized with the ability to track and build an ongoing relationship with contacts. We want more than a glorified address book—we want tools that will help write a story about our constituents: what kinds of communication we've had with them, how they've chosen to support the organization financially or through active participation, how long they've been a member, how we've helped resolve issues and concerns they have brought to us, and other such interactions.
One critical way this story is preserved is through activities—recorded communication to and from constituents, or actions taken on behalf of constituents.
Activity records will be created in one of two ways: automatically by the system in conjunction with some other process, or manually by staff working with records.
Certain activity records, automated e-mails in particular, are created when other parts of the system trigger communication with the contact. For example, if a member renews his membership online, the form will send them a receipt by e-mail, detailing the membership record renewal, payment, and any other data fields completed as part of the process. In addition to the membership and contribution records created by this transaction, CiviCRM records the e-mailed receipt as an activity, providing you a complete picture of every piece of communication sent to the contact. Other examples of automated activities include:
Users with appropriate permission can create certain activity records manually. The most commonly used are records of phone conversations, meetings, or manually generated e-mails (in other words e-mails generated outside of the system). When creating an activity record, you may mark it as complete (a record of a past communication), or schedule it for the future, in which case it becomes a calendared to-do list. In addition, activities may be assigned to other users, providing a useful tool for managing communication among staff members within an office while linking assignments directly to the constituent record.
Several standard activity types are predefined in CiviCRM; you may create new types through: Administer | Option Lists | Activity Types. Activities are created using the Actions list in the contact record summary, drop-down list in the Activity tab, or the Create New button. Activities may have associated sets of custom fields to extend the type of data you collect.
Note that while creating activity types, you may designate them for use with Contacts or Cases. Contact activity types may be used directly with contact records or with case records, but Case types are only visible to case tracking. A full discussion of case management will be covered in Chapter 1
In addition to assigning and scheduling activity records, you can designate priority levels, schedule follow-up activities, and attach files to the record when creating it.
Consider developing a written policy and procedure to encourage (or make mandatory) staff to record every piece of communication they have with constituents. While the habit of looking up contacts and recording activities every time one communicates with a constituent may initially seem cumbersome, you will quickly realize the value of tracking a complete historical log of communications as you build relationships.
Note that the Send an Email activity is special; it does not simply record that an activity took place, but will actually send an e-mail from the system to the specified contact(s). This activity will only be available in the contact record if they have an e-mail address on file.
Inevitably, your interaction with constituents will include collecting personal details about their lives, running into unique situations or circumstances that impact how records were kept, or general information concerning their ongoing involvement with your organization. All of this information is easily stored in notes.
Accessible through a tab on the contact's record, notes provide a simple way to log general information about constituents. Each note includes a subject line, description, and is time-stamped at the time of its creation.
Be careful not to use notes as a catch-all for information better stored elsewhere. In particular, make sure your users understand that activities should be used for communication records with constituents, whereas notes are better used for miscellaneous information about the contact, such as personal details that don't fit into existing contact fields.