The purpose of CER is to keep reference fields in sync with each other. For example, if you have a node ("Alice") with a user reference field, and a user ("Bob") with a node reference field, and you give Alice a reference to Bob, CER will automatically give Bob a back-reference to Alice. If Alice subsequently dereferences Bob, Bob will automatically deference Alice. Or, if Alice is deleted, Bob will lose his reference to Alice.
CER is a powerful module. It allows you to create transparent relationships between different "reference-type" fields. A reference-type field is, simply, any kind of field that references another entity. Currently, CER supports the following field types out-of-the-box:
CER includes a pair of add-on modules that support Profile2 and Commerce Product Reference as well. It also has an object-oriented API that you can use to support other kinds of reference fields, if you need to. Although it's an advanced use case, the API is even flexible enough that you can twist CER's arm into treating things like fields that are not, in fact, fields. A prime example of this is the cer_profile2 add-on.
More information about CER's API can be found in cer.api.php.
When you first install CER, it won't do anything at all until you create at least one preset. A preset is a relationship between two reference field instances, which are referred to as the left field and the right field, respectively. When a change occurs in the left field, the right field will react – and vice-versa.
To use the example above, let's say you have a user reference field called Author, and it lives on Page nodes. You also have a node reference field called My Pages, and it lives on users. You can set up a preset which looks like this:
Node: Page: Author <--> User: My Pages
In this case, Author is the left field and My Pages is the right field. When the Author field changes on a Page node, the referenced user(s) will be updated with a back-reference to the page.
By default, presets are bidirectional. This means that a change on either side of the preset will affect the other side. The example above is bidirectional: you can change Author or My Pages, and the other side will react accordingly.
It's possible, however, to make a preset one-directional, which means that the right side will react when the left side changes, but not the other way around—changes to the right side of a one-directional preset do NOT affect the left side. A one-directional version of our example would act like this:
Node: Page: Author --> User: My Pages
So, in a bidirectional preset, it doesn't really matter which field is on the left and which one is on the right – they'll affect each other equally. But in a one-directional preset, it does matter which side you're on. CER easily lets you "invert" (flip) a one-directional preset.
Internally, CER treats all reference-type fields the same way, so you can put a different kind of field on either side of a preset. For instance, a node reference field on the left side could relate to a user reference or entity reference field on the right side – as long as that user or entity reference field exists on nodes (and, more specifically, one of the node types that the left field is able to reference). CER won't let you create relationships between fields that can't actually relate.
CER presets can be exported with Features. They are exported in hook_cer_default_presets(), in a file called MODULE.cer.inc. When you enable a module that implements hook_cer_default_presets(), those default presets will be instantly available and activated (unless you set the "disabled" flag on an exported preset to TRUE). You don't have to do anything else to import presets. For an example of hook_cer_default_presets(), take a look at the bundled cer_test module, which contains CER's automated tests.