Related tables in forms and cards

A form or record card can include a Related table when a record has independent child records. For example, a Customer form can show its Work items, or a Project form can show its Deliverables. The rows are ordinary records with their own permissions, history, forms, and detail pages. They are not cells stored inside the parent record.

A Related table on a form saves its child records in one of two ways, chosen by your configurator:

• Independently (the default): every child change saves immediately, and a new parent must be saved before children can be added. The sections below describe this behavior.
• With the parent record: child changes stay in the form until you save the parent, and the parent and all its child changes are saved together — or none of them. See Saving related records with the parent.

Record cards always save related records independently.

Before the parent is saved

In an independent Related table, a new parent record has no stable identity yet, so the table does not load or create child records. The form shows Related records will be available after you save this record instead.

Save the parent first, then open it for editing. This prevents a child from being created without the relationship that identifies its parent.

Work with child records

On an edit form or card, each Related table has its own Add and Refresh actions. The table shows ten rows per page and can use either a flat list or the Tree View configured for that child record type.

• Add opens the configured child form. Moltaro supplies and locks the parent Reference, so the new child cannot be attached to a different parent from this workflow.
• Edit opens the child form selected by the table action. Saving changes only that child and refreshes this table.
• Open details opens the child’s Details page in a new browser tab. The parent view and any unsaved form values remain in the original tab.
• Active / Archived switches between current children and the archive. It appears when you have permission to read archived child records, even when the table is otherwise read-only. Add is available only in Active view.
• Archive appears for an active child only when the table configuration and your permissions allow it.
• Delete appears only for an archived child when the table configuration and your permissions allow it. Archive and Delete both require confirmation. Delete is permanent; read the confirmation before continuing.

The compact table intentionally does not include Preview, saved views, filter builder, bulk actions, fullscreen, Manual Order, or an Unlink action. Open the child Details page when you need its complete context.

Related changes save immediately

Child changes are independent

Adding, editing, archiving, or deleting a child record saves immediately. These changes are not part of the parent form draft.

Your configurator can hide the independent-save notice on forms. Cards do not show this notice. Child changes still save immediately when the notice is hidden.

This distinction matters when the parent form has unsaved values:

1. Change a field on the parent without saving it.
2. Add or edit a child in the Related table.
3. The child change is saved and the table refreshes. The parent draft stays on screen.
4. If you cancel the parent form, its unsaved field change is discarded, but the saved child change remains.

There is no transactional rollback across the parent form and the Related table. Finish or cancel each child dialog deliberately before leaving the parent form.

To permanently delete a child, archive it in Active. Moltaro then switches the table to Archived automatically and reloads the row with its current version before Delete becomes available. This two-step lifecycle prevents an active record from being removed accidentally.

Permissions and unavailable states

The parent and child are authorized separately. Seeing the parent does not grant access to its children, and an administrator role does not bypass record security. Moltaro applies the child record’s Entity Security policy before counting and paging rows, then omits fields you cannot read.

Depending on your access and the workspace configuration, the form or card can show:

• an empty state when no readable children exist;
• an access-denied state when the child record type is not available to you;
• a missing-surface state when the configured child Table Surface no longer exists;
• a retryable error if the form, relationship, or table changed while it was open.

Refresh the form after a configuration change. If a required child action is missing, ask the configurator to review the child Table Surface and your Entity Security permissions.

Saving related records with the parent

When a related table saves with the parent, it is part of the form you are editing:

• Add opens the child form. Its primary button is Apply to form: the child is added to the form’s pending changes, nothing is saved yet. You can add children while you create the parent.
• Editing a stored child, or archiving or deleting it, is also a pending change. Archive and Delete ask for an optional reason.
• The pending changes list above the table shows every new, changed, archived or deleted child, with Undo for each.
• A relation that allows at most one child can be shown inline: its fields appear directly in the form. Remove drops a child you started; Archive archives the stored child with the save.
• Choices in a child form that depend on the parent — for example products that must match the parent’s kind — follow the parent values you have entered, even before the parent is saved.
• Create or Save saves the parent and all pending child changes in one step. If anything is refused — a child value, a permission, a record that someone else changed meanwhile — nothing is saved, the error is shown on the parent field or on the pending child, and your changes stay in the form.
• If the connection is lost after you saved, the form says that the outcome is not known yet and stays read-only. Use Check result before doing anything else; Repeat the same save sends exactly the same request again and cannot save it twice; Forget request first warns that the save may already have happened. If you close the form instead, opening the same form again checks the earlier save once and tells you when it was completed.

A section can be shown or required only under a condition on the parent. When a section is hidden, its existing children are kept, block the save, or are archived when you save — as configured. Archiving asks you to review and confirm the records first. Pending changes of a hidden section stay listed so you can undo them. Save stays unavailable while a required section has no record, a hidden section still has pending changes or records to archive that you have not confirmed, or a section’s inline fields are invalid; the section tells you why.

Add in a related table of another record (also in a Drawer or on Details) opens the create form of that record type. When that form has sections that save with the parent, the new record and its children are saved together, and the relation to the record you started from is filled in for you.

Related table versus a Table field

A Related table manages standalone child records; it saves every child operation independently or, when configured, together with the parent. A Table field is owned content inside one parent record; its rows are edited as part of the parent form payload and save with the parent. If the save behavior is unclear and the independent-save notice is hidden, ask your configurator which item the form uses.

For setup instructions, see Configure Related tables. For API automation, see the Related Table developer and agent guide.