CRM Core

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.

CRM Core provides support for identifying duplicate contacts through CRM Core Match. It is designed to allow administrators to control the logical rules through which the system decides whether or not a contact already exists, and pass back consistent information other modules can use to control how records are handled.

Matching Engines and CRM Core Match

CRM Core Match is designed to allow administrators to configure logical matching rules for each contact type in the system. CRM Core Match does not actually do the matching itself; what it does do is process contact information in an orderly way through one or more matching engines.

Matching engines are what actually identify the contacts. CRM Core ships with a module called CRM Core Default Matching Engine, which provides a basic matching engine that is appropriate for most Drupal installations. With it, you can identify duplicate contacts based on the contents of fields in the contact record, by assigning weights to each field and comparing them to a threshold score that indicates when a contact is a match.

CRM Core provides detailed integration with the views module. All of the entities contained in CRM Core can be used together in views to provide detailed tools for interacting with contact information.

A common use case for CRM Core is the need to display a list of recent activities, along with some information about the participants. You might need a list that displays the title of the activity along with the name of the contact who participated.

CRM Core supports this kind of view through the use of relationships. The way to create a view that follows this pattern is simple:

1. Create a new view. Give it a title and a description. Under the show menu, select CRM Core Activities. Press the continue and edit button.
2. On the resulting screen, add a relationship. Select the entity reference: participants option. This will give you access to the fields for the associated contacts.
3. Add fields for the contact record.

At this point, you will have a view that displays information about a contact. In order to add activity information, you need to create a relationship between the contact and the activity. This is easily accomplished through the Views edit screen, by way of the relationships menu.

1. Click the Advanced roll out on the Views edit screen.
   

This page outlines some best practices for creating a feature for CRM Core. These practices are continuing to develop as people work with the module, and more documentation around them will emerge over time.

CRM Core is built as a framework for people to collaborate on the production of small, useful features that extend the use of the module. In order to provide portability around functionality between websites, it is important to build some standards that will allow developers to avoid conflicts between features. Some of these are obvious, and some of these are counter-intuitive depending on how you plan to use CRM Core.

Consider the items listed on this page as guidelines towards guaranteeing interoperability. They will be useful in most cases, but not all. If you are developing a simple feature you plan to distribute for CRM Core, they will serve you well. If you are planning to build an install profile that will provide users with a pre-configured CRM system, there may be reasons to deviate from the guidelines listed here. Use your judgement, and ask questions in the issue queue if there is something you are wondering about.

Use a Unique Namespace

Every feature developed for CRM Core should have its own unique namespace. This namespace should be reflected in all the elements used by your feature: field names, content types, views, paths, etc.

CRM Core does not aim to be a CRM system on its own, so much as a tool for building CRM functionality in a Drupal site. This means someone could be looking to build a site just for managing contact relationships, or looking to build some CRM-style functionality in a site with an existing front end that allows interaction with contacts.

To this end, the developers made no assumptions about the UI except for the fact it needs to work with themes that ship with Drupal - it's left open so that site builders can define the UI elements that make the most sense in their use case.

This is both a benefit and a drawback to people developing for CRM Core. When designing a new module, feature or component, it is important to consider the fact that the UI is not static and people will use your code in different ways. Nothing is more frustrating than a link that displays in the wrong place and can't be turned off, just as nothing is more challenging than looking for administrative tools that are not where you would expect them to be.

CRM Core provides a number of UI elements that developers should be aware of. This list deals with the items themselves along with best practices for how to work with them.

Reserved Paths and the CRM Section