Core Differences
While repeatable sections and record link fields may seem similar, they serve different purposes and have distinct behaviors. Here’s what you need to know to choose the right approach.
The main structural differences are:
Repeatable sections create a one-to-many relationship within a single record
Record links enable many-to-many relationships between separate apps
Record links were designed for lookup table functionality, allowing data from linked records to populate fields in the main record
When to Use Each Type
Use Repeatable Sections When:
The child data only makes sense as part of the parent record
You need to collect simple, contained information (like photos and notes for each hazard in an inspection)
The child records don’t need to be accessed or managed independently
You have fewer than 50 child items (larger numbers can impact performance)
You need the data to be included automatically in PDF reports
You want to guarantee child records can’t be orphaned from their parent
Use Record Links When:
The linked data needs to stand alone as its own entity
Multiple teams need to access or manage the linked records
You need to reference the same item across multiple parent records
You expect to have many items (50+ linked records)
The linked data needs its own workflow or lifecycle
Other apps need to link to these records
You need lookup table functionality
Real-World Examples
Instead of abstract concepts, here are concrete examples:
Good Uses for Repeatables:
Photos and notes within an inspection
Simple material lists used only by the inspector
Measurement readings at a single location
Quick observations that don’t need tracking
Good Uses for Record Links:
Invoices that finance needs to track separately
Equipment that multiple inspections reference
Hazards that become their own inspections
Daily inspections that accumulate over time
Assets with unique locations (like utility poles)
Technical Considerations
Performance and Storage
Records with repeatables have a 5MB JSON size limit
Large numbers of repeatables (50+ items) can slow mobile app performance
Record links distribute data across separate apps, improving performance
Repeatables must be updated as a complete unit - changing one child record requires rewriting all siblings
Data Management
Repeatable data is atomic - child records can’t exist without their parent
Record links offer more flexibility but require managing relationships
Repeatable sections maintain inherent ordering of items
Record links need manual index management if order matters
Exports
When exporting repeatable sections, the exported ZIP folder will contain separate data files for the main record data and the child record data.
Alternatively, when exporting records with record link fields, the linked app’s data is not automatically included in the exported ZIP folder. You must run an additional export for the linked app fields. (You could also use the auto population functionality to pull in specific field values from the record linked app.)
Linking Data Together Outside Of Fulcrum
The child data file from a repeatable section will contain two columns that link the child record to its parent record. The first column is called fulcrum_parent_id. This column contains the fulcrum_id (record ID) of the immediate parent for the child record. The second column is called fulcrum_record_id. This column will be filled with the fulcrum_id (record ID) of the root level record. So in the event that you have nested repeatable section, you will be able to link the child record to both the root level record and its immediate parent record.
Unlike repeatable sections, to link records back to each other outside of Fulcrum, you will need to look at the data file that holds the data for the app that has the record link field in it (parent data file). In the column that stores the record link data, you will see the fulcrum_id (record ID) of the linked record(s). This column can be used to locate the correct ‘sub-records’ in the data file that was exported from the app that is linked to the record link field.