The power of a case management system is in the custom structures to put details into relation: Link your participants to the partners, activities, survey responses and tasks that you need to manage. This allows you to design a 360° view of your cases. And it builds a powerful database of all data that you can analyse in many ways.

This guide describes how you can configure the data structures between different record types.

You create a relationship from one record to another record with a "link to another record" field in one of the records.
The other record can then automatically list all the records that link to it, also.

For example, let's consider the scenario of Students and Activities in which students participate in:

The record linking to another record:

In this case, we would add a field to the Activity data structure with a type "link to another record" (also see "Adding a new field to a profile form"):

(Relationships can be a one-to-one or one-to-many, if you enable the "multi-select" option for the field)

When you edit a specific Activity, you can then select any of the existing Student records (or create a new Student):

The record being linked to from another record:

You do not need to explicitly update any details in the Student's profile. The relationship is automatically available on both records.

To display the Activities that link to a particular Student in that Student's profile, you can add a new "Related Entity Section" in its Details View through the Admin UI:

Then select the "Entity Type" of the related records that you want to list:

In our example, we want to list the related Activity records. The system will automatically only show those Activities that are linked the the Student whose details you are currently showing. You can also select which of the fields of the Activity you want to show in the section in the Student details.

If the "Record Type" in the Admin UI for the Related Entity Section doesn't contain the type you are looking for, make sure that that type has a field with type "link to another record" that links to this record type (see above).
For our example: The Activity record type must have a field that links to "Student" records to be available here.

After you added the student to one or more activities by editing the activity, you will automatically see all activities that link to the current student:

You can also add new Activity records here from the student's details, using the (+) icon on the embedded table.

General considerations about designing relationships

When to work with different record types and relationships (instead of putting everything in one record)

You can apply the structure above to any kind of relationship between records. For example:

• Exam results linked to a student

• Survey responses of a participant

• Details of multiple family members in a household

• ...

Especially if you need to record multiple items with the same structure, making that a separate record type that links back to the primary type is useful.

Also, if you don't know how many items you need to record (e.g. how many family members are there?).

Or if you want to record multiple observations over time (e.g. do an annual survey and monitor the progress over the years).

Which of the records should contain the "link to another record" field?

Often there is a clear, logical hierarchy in the things your records represent: For example, a survey response is a "secondary" detail related to a participant while the participant record is a more central "primary" thing in your system. In this case, add a field to the secondary record to select the linked primary record. That way you can easily list multiple related secondary details in that primary record.

If you are designing a one-to-one relationship and there is no clear hierarchy, either record could be suitable to hold the field. Consider the example of the resulting user interface above: Maybe one of the records seems more natural to hold an "indirect" link (through an embedded table in its details view) than the other.

It is not advisable to add a "link to another record" field to both record types, however. That would mean you need to edit both records or may have confusing and inconsistent data, if only one of the records' link is filled.

Using a secondary record type to limit access through permissions

Aam Digital can control access to different data through user roles. However, these permissions always grant access to all fields of record. If you have some details that are more confidential, you can create a separate record type that links back to the primary profile. Access to that secondary record can then be more limited to fewer users (e.g. the contact details of a student can be a separate record type that is only available to the project management).