Nested Data Fields

Business data often comes in groups. An address isn't a single field — it's street, city, postal code, country. A contact isn't just a name — it's name, email, phone, and preferred contact method. These groups of fields belong together conceptually and practically.

Treating them as isolated flat fields creates problems: they're harder to display, harder to validate as a unit, harder to reuse across multiple object types, and harder to export in a structured way.

Nested data fields solve this with structure definitions.

Define a Structure Once

A structure is a reusable field group. Define it in the registry — name it, add its sub-fields, configure types and validation for each. An "Address" structure might have: street (text), city (text), postal code (text), country (dropdown).

Once defined, that structure can be applied as a field type on any object type. Add an "Address" field to Customers, Suppliers, and Delivery Locations — each one uses the same structure definition, with the same sub-fields and the same validation rules.

Clean Rendering in Forms

When a structure field appears in a form, the platform renders it as a distinct fieldset with its own visual grouping. The sub-fields are organized within the group, separated from unrelated fields.

The visual grouping reinforces the conceptual grouping. Users understand that these fields belong together and should be filled in together. It's also easier to scan — an address block at a glance, not six fields scattered through a long form.

Detail Views Show Structure

In read-only record views, structure fields render as organized blocks rather than flat key-value pairs. An address appears as a complete, formatted block — not four separate lines with field labels.

This makes records easier to read at a glance. Compound data reads naturally; the structure matches what users expect the information to look like.

Validation at the Structure Level

Validation rules apply at the sub-field level within a structure. A postal code field can validate format. A country field can be required. When one sub-field fails validation, the entire structure group shows the error in context.

Because validation is part of the structure definition, it applies consistently everywhere the structure is used — no need to configure the same rules on every object type that uses the structure.

Reusability as Standard Practice

The most significant benefit of structure definitions is reuse. Define an address structure well once, and every object type that needs an address gets exactly that structure — with the same fields, the same validation, the same rendering.

When you need to add a field to the address structure — a region code, a delivery instructions note — you add it to the structure definition, and it appears on every object type that uses it.