Skip to content

Relationships between records

Records rarely stand alone. A service request may refer to a customer, asset, location, contract, or previous inspection. Relationships let users move through that context without copying the same facts into every place.

Moltaro has a small set of named relationship mechanisms. Users mostly experience them as links and related lists, but knowing the names helps when reading configuration or API documentation.

A direct self-Reference can also be selected as the edge for a Parent Tree View. This is a presentation of stored parent records, not a generic relation, Catalog hierarchy, or value-based Group By.

A Reference is a field that points from one record to exactly one other record. The source record stores the link, and the target record remains its own governed object with its own fields, history, permissions, and lifecycle.

For example:

  • a service request references the affected asset;
  • an inspection references the site where it happened;
  • an approval references the request it belongs to.

Depending on configuration, a reference can have visible consequences beyond the link itself:

  • deleting or archiving a referenced record can cascade to the records that point at it, so dependent records disappear or archive together;
  • a record’s changes can be configured to appear in the referenced record’s history, so the parent record tells the full story.

The reverse side of a reference can be shown as an Inverse reference: a list on the target record of everything that points at it. An asset can list its service requests; a contract can list the cases that reference it.

These lists drive the related sections on detail pages and can feed summary values such as counts or totals over the linked records.

When many records connect to many records — people to projects, products to suppliers — Moltaro uses an association: a separate record type whose records represent the links themselves.

Each association record connects one record on each side and can carry its own information about the link, such as a role or a validity date. Association records are ordinary governed records with their own history and permissions, and both connected records show their associations in related sections.

Some information belongs inside one record as child rows of a Table field. Child rows do not have their own lifecycle, comments, access, or detail page — they are part of the record. Use child rows for line items and repeated details; use references or associations when the connected object needs its own life.

References, associations, parent-tree presentation, and catalogs describe business structure. They do not implicitly grant Entity access. A Security Statement may traverse an explicitly catalogued reference and test target facts, but both source projection and referenced preview remain independently governed by root View and field Read permissions.

Two nearby features are not record-to-record relationships:

  • Assignments connect a record to responsible people or groups (owner, assignee, reviewer). See Responsibility and assignments.
  • Board item links connect process items on a board (parent, child, related). They belong to the board, not to the underlying records. See Links between items.

Reading one record does not automatically grant access to every linked record. If a user can read the source field but not the referenced target, Moltaro does not project target details. A link can also show as not found when the target record was permanently deleted without cascade.

This keeps the relationship honest without leaking information.