Working with Repeating Data (Collections) in Streamline – Streamline

Many real-world records contain repeating data: an invoice with many line items, an order with several products, a patient with a history of visits, or an account with multiple contacts. In Streamline, a set of repeating records is called a collection. This article explains what collections are, where they come from, which steps work with them, and what happens in steps that do not.

Tip: A collection is just a list of records that share the same shape. Each item in the collection has the same fields, the same way each row in a spreadsheet has the same columns.

What Counts as Repeating Data

Streamline treats the following as collections:

Lists of records (arrays). A group of objects that share the same fields, such as a list of line items, each with a SKU and a price.
Keyed lists (object-based lists). A set of records identified by keys. Streamline converts these into a list and preserves each key as an id field.
Lists of simple values. A list of values such as tags or IDs.

Collections can also be nested. A parent record can contain child records, and those child records can contain their own records, for example an order (parent) with line items (children), and each line item with sub-items (grandchildren).

Where Repeating Data Comes From

Repeating data enters a workflow from a few sources:

Incoming Webhook step. When an external system sends a JSON payload that contains arrays, Streamline detects those arrays and turns them into collections automatically. See Using Repeating Entities with the Incoming Webhook Step.
Search Data step (related records). When you search a connected data source, you can include a record's related child and grandchild records. Each related relationship becomes its own collection. Related-record search applies to connected data sources. See Using Repeating Records in the Search Data Step [add the link]
Forms (repeating sections). A form can include a repeating section so a respondent can add multiple entries (for example, several dependents or line items). Each repeating section produces a collection. See Using Repeating Records in Forms [add the link]

However a collection enters the workflow, it behaves the same way in the steps that follow.

Which Steps Work With Repeating Data

Some steps can read and render an entire collection in a single run. Others do not work with collection data at all, because they act on a single message or document rather than a set of records.

Steps that work with repeating data today

Step	What it does with a collection
Incoming Webhook	Detects arrays in the incoming payload and stores them as collections for downstream steps.
Search Data	Retrieves a parent record with selected child and grandchild records from a connected data source.
Forms	Shows, collects, and edits repeating records in a Repeating Section.
Document Generation	Repeats tables, lists, or text sections once per record in a collection.
Deliver Data	Writes a collection of records back to a connected data source.
Outgoing Webhook	Expands collections into JSON arrays in an outbound webhook payload.

What Happens in Steps That Do Not Support Collections

When a step does not support collection data, it may not expose collection fields for mapping, or it may only use a single value from the collection depending on the step.

At run time. If a field points to a collection in a place that only expects a single value, some steps may use only the first record. For example, in Document Generation a field path that does not match an active loop renders only the first item.

Tip: If a step only shows the first record of your data, check whether that step supports collections and whether your fields are mapped to the collection correctly.

Limits to Keep in Mind

These limits apply across every step that works with repeating data. Individual steps may have additional limits; see each step's article for specifics.

Nesting depth. Workflows support up to two levels of nesting below the parent record (parent > child > grandchild). Deeper hierarchies may be received but are not rendered or written back end-to-end.
Collection size. A collection can hold up to 1,000 for primary records. Keep collections to what the workflow needs; very large collections can affect performance.
Collections per payload. A single workflow payload can carry up to 50 collections.
Fields per collection. Each collection can contain up to 50 fields.
Label length. Collection and field labels are limited to 100 characters.
Payload size. Collections are stored externally (see below) so they do not count against the workflow engine's payload limit. Inbound webhook payloads are capped at 5 MB (a warning is logged at 2 MB).

Behavior limits that affect how you build

One collection source per repeating section or write-out. Repeating records are bound to a single collection source per repeating section in a Form or per write-out entity in Data Delivery. You cannot combine fields from two different collections into one. For example, if a workflow runs two Search Data steps that return different entities, you cannot mix mappings from both into a single Form repeating section, and you cannot combine records from a Search Data collection and a separately edited Forms collection into one Data Delivery write-out. If a workflow carries multiple collections, each one must map to its own repeating section or write-out entity.
Include the source record's ID or key field for write-back. If a downstream Deliver Data step will update existing repeating records, the Form must include the source record's ID or unique key for each repeating record, even if that field is hidden from the user. Without it, the workflow cannot tell which edited record maps back to which existing source record.
You cannot delete or disassociate existing repeating records. Streamline does not support deleting existing repeating records from a data source, or disassociating child records from a parent, through the repeating record UI. You can edit existing repeating records and add new ones, but you cannot remove or disassociate records that already exist in the connected data source. Removing an existing pre-populated record in a Form is a session-only change; the record reappears in future sessions. To permanently remove or disassociate records, make that change in the connected data source directly.
Calculations on repeating data are not available in the initial release. Field calculations that operate across repeating records are not supported yet.
Outbound Webhooks expand collections in JSON only. XML, CSV, multipart, and raw binary formats are not supported for collection payloads.
Document Generation loops require a DOCX template. Native PDF form templates do not support loops. PDF delivery is still available by rendering the DOCX and converting to PDF.

Format support by step

Step	Format constraint
Outbound Webhooks	JSON only
Document Generation	DOCX template required for loops (PDF available via conversion)