Skip to content
MoltaroMoltaroMoltaro Docs

Related data

Related data is information shown around a record because it helps explain the record’s context. It may come from reference fields, linked records, child rows, module records, board items, comments, files, activity, or configured related sections.

The goal is to help users understand the current record without losing the separation between different business objects.

Section titled “What related sections are for”

Related sections can answer questions such as:

  • which records point to this record;
  • which records this record points to;
  • what child details belong with this record;
  • what process work is connected to it;
  • what evidence, comments, or activity exists around it;
  • which module-specific records, such as board or entitlement records, are part of the same work.

The exact sections depend on the record type, enabled features, modules, and the current user’s access.

An administrator can also add a related table through one referenced record. For example, a participant record can reference a beneficiary and show that beneficiary’s history. Other records pointing to the same beneficiary can appear in the table even if they do not point directly to the participant. This option is available in configured Details and Drawer sections.

The table follows the currently selected beneficiary. If the reference is empty, the section shows an empty state or is hidden, according to its configuration. Access to the reference, the beneficiary and the history is checked separately. This type of section does not offer a contextual Create action; available actions on existing rows still depend on permissions.

Section titled “Related data is not always editable”

A related-data section may be read-only, editable, or action-driven. Some sections let users create linked records. Some only show a filtered list. Some open a picker, drawer, board item, entitlement, or another record detail page.

If a section is present but an action is missing, the user may have read access without create, update, assignment, or module-specific permission.

Choosing where information belongs

Section titled “Choosing where information belongs”

A record should hold the facts that describe that business object. Related data should be used when another object has its own meaning, lifecycle, access, or history.

As a practical rule:

  • use a field when the value is a direct fact about the record;
  • use a child row when repeatable detail belongs inside the record;
  • use a referenced record when the linked object should exist independently;
  • use a board when the important thing is process movement, queueing, or handoff;
  • use object collaboration for supporting discussion and documents, tags for flexible classification, and activity for orientation rather than core structured data.

Access-aware context

Section titled “Access-aware context”

Related data follows access rules. A user may see one section and not another. A section may show fewer records than another user sees. A link may be visible but resolve to a restricted record if the user cannot read the target.

This keeps detail pages useful without turning them into a bypass around record or field permissions.

Where to go next

Section titled “Where to go next”