CiviCRM Entity Reference Field is a submodule of the CiviCRM Entity project. One of the many advantages of installing the CiviCRM Entity module is the ability to use Drupal’s Entity Reference module to reference CiviCRM data from nodes, terms, or other entity types. Many people are using the Inline Entity Form module, which provides field widgets that allow you to create, edit, or delete a referenced entity from the parent form.
If you reference CiviCRM contacts via an Entity Reference field and use Inline Entity Form, you’ll often want to include the ability for the user to create or edit subsidiary CiviCRM entity types, such as the email, phone, and address entities. This can get tricky with CiviCRM integration. A regular entity reference field stores a target entity id in a Drupal field table of the Drupal database. CiviCRM Addresses are stored in the CiviCRM database, and can be created by different types of users and in many different ways. In addition, Drupal and CiviCRM reference data in opposite ways. Drupal’s field model, “forward references,” which means the entity stores the ids of the child entities. CiviCRM generally uses “backreferences,” meaning the child entity will store the parent entity’s id. To make the situation even more interesting, this pattern is not consistently followed in CiviCRM, and you’ll occasionally have a “forward reference”. For example, events store a location block id, and the location block references addresses.
We want the convenient and familiar interface of the Inline Entity Form/Entityreference combination, but we want to use the existing data from the CiviCRM tables, and not store target ids in Drupal field tables, while at the same time being flexible enough to go both ways. We want to make a square peg to fit into a round hole. What we needed was a “remote reference field”.
The Drupal Field API is very powerful, and it allows you to make field types that are disconnected from the standard Drupal field tables. The solution is CiviCRM Entity Reference Field, which adds a new field type that can be added to any CiviCRM entity type.
We’ve successfully used this module for a variety of use cases, including:
- Referencing emails, addresses, phones from contacts
- Referencing participants from events
- Referencing relationships from contacts
- Referencing activities from contacts
- Referencing contacts from activities
- Referencing contacts from relationships
It is also possible to have CiviCRM Entity Reference (CER) fields on entities referenced by CER fields. For example, In CiviCRM, Events reference location blocks, which in turn reference addresses. To edit profiles on Events, you need to reference UFJoin from Events. The UFJoin entity type needs a UFGroup reference field which needs to reference UFField. That case is especially interesting as that “line of reference” runs both forward and backwards from the UFGroup entity.
That’s the what and the why, to see an example of how to use it, please continue reading this article on Skvare.com.
