Reverse links (also called backward references) are a general implementation of many-to-many relationships between records. You implement reverse links if you want databases that are linked to each other by means of linked fields with a link reference, to update each other when in records linked terms are filled in, edited or removed, for instance when you add or remove a record, or when you edit, add or delete a keyword in either database.
Let's say you have a books database and a thesaurus, and in thesaurus records you want to list all the books that refer to the current keyword. If you wouldn't use reverse links, said list of books in keyword x would not be updated if you removed a books record or if you added a books record with a link to this keyword; and the list of keywords in a books record would not be updated if you added or removed a keyword record with a link to this book.
So you have to use reverse links if you want two linked databases to automatically and mutually update each other when linked terms are entered in either of both databases.

To implement this functionality you must specify a reverse link in both databases that are linked to each other. You can only provide a reverse link in a database if there exists a link reference tag for the field you link to in the other database, and if there is an index on that link reference field; and  the tag you provide for a reverse link in one database must be exactly the same as the link reference tag of the field you link to in the other database. So with a reverse link you point to the link reference tag of the field you link to, so that the record number of the record from which you link is stored in (an occurrence of) the link reference tag of the linked record in the other database.
So if  you would create e.g. four "primary" records that link to one and the same record in the "linked" database, the record numbers of these four records are stored in the link reference tag occurrences in said record in the linked database. (Note that the terms "primary" and "linked" are interchangeable when talking about reverse links, because each database is at the same time primary and linked.)

Let's illustrate this by the following more elaborate example. Say we have two databases, Objects and Photographs, with the following characteristics:

And suppose we have three objects: O1, O2 and O3. Photographs have been taken of two of these objects: F1, F2 and F3. Object O1 is on photographs F1, F2 and F3; object O3 is also on photograph F2. There are no photographs of object O2 in the database. This results in the following tables:

The above list shows the following information for each of the objects and photographs: the record number (%0); which stock numbers are on which photographs, which photographs the objects are in, and the number of the link reference that ensures the link between object and photograph.

If you click for instance the third photograph number of object O1 in the record for object O1 in the Objects database, you zoom straight to the details of photograph F3. In the same way, you can zoom to object O1 if you are on the linked field "in" of the photograph F3 record. Any modifications made in the objects database that have consequences for the photographs database will be automatically implemented in the photographs database, and vice versa.

So because certain data must appear in both databases, you have to specify that the two databases are linked, and define the link reference tags and reverse tags for the both of them. Then whenever data that appears in both databases is modified, the system can update it in the other database.

Note that some changes, like changing a preferred term in an authority database into a non-preferred term doesn't update reverse linked fields to the new preferred term. And if you delete a record with a reverse link, the system doesn't warn you if any references in other databases to this record exist and are going to be removed when you use or open records with those references. For this type of updating you need feedback links, instead of reverse links.

Reverse links processing in a read-only linked database

Suppose you have set tight access rights to your databases to make sure that some user group, let’s call their role “repromanagers” for example, can only edit records in the MEDIA database (the Multimedia documentation data source) and has read-only rights to COLLECT (the objects data sources) while another user group, with role “objectmanagers” for example, has the opposite rights (allowed to write object records while only being allowed to read reproduction records). Since in current applications MEDIA and COLLECT are reversely linked databases – object records can link to multiple reproductions while each reproduction record can link to multiple object records – this setup could in principle cause problems, but Collections implements a less strict policy in this regard: it will ignore read-only access rights to reversely linked databases as far as the processing of reverse links is concerned. So in the example above, the “repromanagers” will be allowed to add linked objects to a reproduction record, while the “objectmanagers” will be allowed to add reproduction references to object records. Each user group will still not be able to edit records in the other database though.

If the access rights need to be tightened further still, for example to prevent the “objectmanagers” from adding reproduction references to an object record, then you could protect the reproduction reference field and its link reference field in the COLLECT data dictionary by assigning the “objectmanagers” role read-only rights to these fields. Then the only way to create reverse links between objects and reproductions would be if the “repromanagers” added linked objects to reproduction records. The reverse links would be processed automatically when saving a reproduction record and they would become visible (read-only to both groups) in the relevant object records.

Note that although the example assumes two user groups with opposite rights, a setup in which only a single user group (role) needs to be able to write reverse links in a read-only linked database, applies just as well.

See also

Linked fields introduction

Make a field linked

Linked field properties