Site administrators

The redhen_contact module provides the central RedHen Contact entity.
User Interface: redhen/contact
Configuration: admin/structure/redhen/contact_types

Record Types
Like a Drupal Content node, the entity's structure is largely defined by the site builder. You must create at least one Contact Record Type (or "Entity Bundle" in Drupal-speak) before you can create any Contact records ("Nodes" in Drupal). For most use cases, creating a single Contact Record Type is recommended -- you can always distinguish varieties of contacts using a custom field.

All Contact Types start with two basic data fields: the Contact Name and the multi-value RedHen Email field (see Fields). RedHen will enforce uniqueness on your system amongst RedHen Contact Email addresses. Contact Types have some more complex fields baked in as well, some of which only appear if you have particular modules enabled:

• user: If you are connecting RedHen Contacts to Drupal Users, this is the field that connects them.

The redhen_fields module contains custom field types used in RedHen. As of version 1.3, this only includes one field type: RedHen Email (redhen_email). This multi-value field is used by the RedHen Contact entity, and allows for tracking email addresses along with some useful CRM metadata. Each email address in a RedHen Email includes the following fields:

• A Label drop-down with 2 options: Home and Work. You can add more by editing the field settings on a given Contact Record Type (Bundle).
• A Primary checkbox, which can only be enabled for one of the email addresses, and is then used to match a RedHen Contact to a Drupal User if you enable that function.
• A Hold checkbox, which can be set independently for each address to indicate that emails to this address should be suspended.
• A Bulk checkbox, which can be set independently for each address, and indicates that this is one of the Contact's preferred addresses for bulk email.

To give a clearer sense of what RedHen offers, and to help you determine which modules you might want to use in your RedHen project, we have broken down what each sub-module offers in the following sub-pages. They are ordered loosely by core importance and increasing dependency: the modules near the top are often required by those at the bottom. For more on dependencies, see the Module Breakdown on the RedHen intro page. The Contact and Organization modules will be used in almost every case, so you might want to start with those if you are in the exploratory phase.

RedHen is a lightweight, Drupal-native CRM framework. CRM stands for Customer Relationship Management*, and the initials "CRM" are often used to refer to a software tool designed to assist with Customer Relationship Management (so "CRM" really means, "Customer Relationship Management Tool" as we use it).

CRM Core was designed to be very flexible when it comes to identifying duplicate contacts. In terms of how a duplicate is defined, the designers of CRM Core concerned themselves with use cases having duplicates living in the following spaces:

• In CRM Core, as a contact
• In CRM Core, as a contact of a different type
• In Drupal, as defined in some other module
• In some other database, accessible via a direct database connection
• In some other system, accessible via web services

CRM Core Match was built to provide support for each of these, not directly, but through the use of matching engines. A matching engine is a tool used to identify duplicate contacts, wherever they may live, and according to whatever rules are important in your situation. It also allows developers to directly modify a contact record as part of the matching process. This can be very useful in situations where, for instance, CRM Core Match is being asked to identify duplicates in an external system and you need to keep a record of the external identifier for use in other situations.

Module developers working with CRM Core often need to know what fields are being used to store the primary phone numbers and addresses for a specific contact. At the same time, it's impossible to predict the specific fields someone would configure for CRM Core beforehand.

In order to overcome this problem, CRM Core provides the ability to select primary fields for each contact type. Primary fields are really just flags, telling other modules that primary email addresses, postal addresses and telephone numbers live in specific fields in your contact records. There are some modules and features that will not work unless the primary fields are properly configured.

You can set the primary fields for any contact type by going to main page for editing the contact type. This can always be found in the administration section of your Drupal website by going to Admin > Structure > CRM Core > CRM Contact Types, or by going directly to admin/structure/crm-core/contact-types. Simply click on the edit link for any contact type, and you will be taken to a screen where you can choose the primary fields for storing contact information.