Related and sub-table records

Automations often need to reach beyond the trigger record — to the records it links to, or to the line items entered on it. Related records and sub-table rows look similar but behave differently in a flow, so this page covers each.

A lookup field links records in two tables. In a flow you can read across that link in either direction and write to it:

  • Read the linked records — use the Get Related step (or records_related() in code) to fetch the records tied to a source record, then a For Each loop to act on each. Get Related reads incoming links (e.g. from a Customer, its Orders) or outgoing ones (from an Order, its Customer).
  • Follow a single link inline — a single lookup field exposes {{record.lookupField.id}} and {{record.lookupField.title}} tokens, so you can reference the linked record without a step. To load its other fields, feed that id into a Get Record step.
  • Set or change a link — in Create Record or Update Record, set the lookup field to the related record's id (a {{…id}} token works). For a multiple lookup, pass a list of ids, or a multiple-field token that already holds several.
  • Iterate a multiple lookup — a multiple lookup token holds a list; loop it with For Each to process each linked record.

Sub-table records (line items)

Sub-table rows — invoice lines, order items — are weak entities: they exist only inside their parent and are saved atomically with it. That shapes what a flow can do:

  • Add, change or remove a line with the Add Line Item, Update Line Item and Remove Line Item steps. Each one asks for the parent record, which of its line-item tables to write, and the values. Update and Remove also want the line to act on: use {{line.id}} from a Get Related loop. In code these are record_line_add(), record_line_update() and record_line_delete().
  • The parent refreshes automatically. Adding or changing a line changes the parent's rollup totals, so each of these steps hands back the updated parent. A step further down the flow reads the new total from {{record.<rollup field>}}, not the value from before the flow ran.
  • You cannot point Create, Update or Delete Record at a line-item table. Those steps write whole records, and a line only exists inside its parent. The flow editor does not offer line-item tables there, and saving a flow that names one is refused. Use the line steps above, or the public API's master-detail endpoints.
  • Read a record's lines: use Get Related / records_related() from the parent to the sub-table, or records_query() on the sub-table filtered by its owner field, then For Each to loop the lines. Line-item tables appear in the Get Related list labelled "(line items of ...)". Inside the loop each line offers its own field tokens plus {{line.id}}, which is what the Update and Remove steps need.
  • Skip the loop for totals — a Rollup field on the parent already holds the sum/count/average of its lines. Reference it as {{record.rollupField}} instead of summing lines yourself.
  • Triggers fire on the parent. Saving a record with its lines runs the parent's On Create / On Update automation — editing lines is part of the parent save, not a separate sub-table event. Rollups are recomputed before the trigger runs, so {{record.rollupField}} is already current inside the flow.
  • A line written by a flow does not start another flow. Like every other write a flow makes, it does not re-trigger automations. That is what lets an On Update flow add a line without setting itself off again.

See also: Automations · Sub-tables (line items) · Tables and fields