Repeating Sections

With Repeating Sections, a single form can show, collect, and edit a set of repeating records, such as multiple visit records on a patient or line items on an invoice. Builders turn a form section into a Repeating Section, and end users work with multiple records in one place instead of completing a separate form for each record.

Note: This article covers working with repeating data (collections) in the Form step. For general setup of the step, see the Form step help article. [https://help.intellistack.com/hc/en-us/articles/45899217034515-How-to-Create-and-Use-the-New-Form-Step] For an overview of repeating data across Streamline, see Working with Repeating Data (Collections) in Streamline.

Who Has Access?

Repeating Sections do not have separate role gating. Access follows standard Streamline role permissions.

Key Capabilities

• Render each record as a form section. Every record displays as a form section supporting multiple field types.
• Use with or without prefill. Configure a Repeating Section without prefill when end users should add all records during the session. Configure prefill by mapping the section to an upstream collection from an Incoming Webhook or Search Data step when existing records should appear in the form.
• Add to and edit repeating records. End users can edit pre-populated records add new records in Repeating Sections. Newly added records can be removed before they are written to a data source.

Part 1: Add a Repeating Section

1. Open the workflow in the builder and select the Form step.
2. Add a Section to the form.
3. Click the repeating icon in the top-right corner of the section to turn it into a Repeating Section.
4. Add the fields you want to collect for each record inside the Repeating Section.

Note: A field placed directly on the page, outside a Repeating Section, cannot be made repeating. Repeating behavior applies to the section and the fields inside that section.

Note: You can add a nested Repeating Section inside another Repeating Section, but nesting is limited to two levels. Deeper repeating sections are not supported.

Part 2: Pre-Populate the Section, Optional

If you want the section to be prefilled, map the Repeating Section to an upstream collection from an Incoming Webhook or Search Data step.

1. Confirm the upstream step produces the collection you want to show in the form.
2. Map the Repeating Section to that collection.
3. Confirm fields from the collection appear inside the Repeating Section.

Note: You cannot mix fields from different collections or different upstream steps in the same Repeating Section.

Note: If the section should prefill from a connected data source, the upstream Search Data step must return a collection. Make sure the dataset enable Repeated records for each object that should populate as repeating data. If the object is not enabled for repeating, the Form cannot prefill that object as a Repeating Section.

Part 3: Add Static Fields

Add any static, non-repeating fields on the form needs to be outside the Repeating Section. Static fields cannot be placed inside the Repeating Section. Instead, place static fields directly on the page or a seperate non-repeating section.

Part 4: Add, Edit, and Remove Records in a Session

In a session, end users can:

• Add a record to create a new record in the submitted collection.
• Edit values in any record.

• Remove a newly added record before the form is submitted.

  Note: Remove an existing pre-populated record from the current session. This does not delete the record from the connected data source, and the record reappears if a new session starts for the same parent record.

Example: Patient With Multiple Visit Records

A patient intake workflow receives a patient record with several existing visit records. The Builder adds a Repeating Section to the form and maps it to the Visits collection.

When the form runs:

• The patient's standard, non-repeating fields display normally.
• Each existing visit renders as its own full form section, pre-populated and ready to review.
• The end user edits an existing visit, adds a new visit, and removes one entered in error.

Feature Considerations

• One collection per section. Fields from the same entity or collection must map to the same Repeating Section. You cannot mix fields from different collections in one section.
• Maximum nesting depth is two levels.
• Nested repeating entities must be mapped in hierarchy order. You cannot directly map the third level (grandchild) without also mapping the second level (child). A level-2 repeating entity cannot be mapped directly to a page or to the first level of a Repeating Section; it must be nested under its parent Repeating Section.
• Maximum 1,000 items per collection at the primary level. This is a size-based restriction. Deeper levels are bounded by the activation engine's depth-based fetch limits (roughly 50 at the first nesting level and ~16 at the second by default).
• Conditional logic works at the section level, not per record. Within a Repeating Section, logic can compare fields inside that section to each other or to fields in static (non-repeating) sections, and the collection can be used as a whole in conditional logic. You cannot use conditional logic to filter, show, hide, or branch individual records within the collection (for example, "if a repeating record's value starts with A, do this; if it starts with B, do that").
• Repeating data cannot be used in calculations. Calculations do not operate on repeating record values in the initial release.
• Existing pre-populated records cannot be deleted from the data source. If an end user removes an existing pre-populated record from the form, it is only removed from the current form submission. The record is not deleted or disassociated in the connected data source, and it appears again the next time the form loads data for the same parent record. To permanently remove or disassociate the record, make that change in the connected data source directly.
• 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 other unique key field 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, and Data Delivery cannot update the correct records.
• Up to 50 fields per collection. A Repeating Section bound to a collection supports up to 50 fields. If a collection has more fields than the workflow needs, map only the required fields.
• Maximum label length is 100 characters. Collection and Repeating Section labels are capped at 100 characters.

Troubleshooting Common Issues