Scope, cardinality, and relations are three overlapping ideas that answer one family of questions: how many copies of this item are there, who owns each copy, and how do pieces of data point at each other? Getting these right is what separates a clean, multi-applicant workflow from one that generates duplicate or missing submissions.
Making a form or section repeatable
If you want users to add the same thing over and over — more assets, more properties, more employers — that's what cardinality controls (and, for a question inside a form, a repeatable sub-form). Instead of one fixed copy, you set a minimum and maximum number of instances and the user keeps adding entries — "add at least 2", or "add up to 5", or as many as they like. So "make this form repeat", "let them loop this section", and "add multiple of these" all come down to scope (who gets a copy) and cardinality (how many), both covered below.
Scope
Scope controls how many independent copies of an item exist on a deal when there are multiple applicants.
| Scope | How many copies | Who fills each copy | Use it for |
|---|---|---|---|
| Shared | One for the whole deal | Any team member or applicant | Deal-level facts: the property, the loan amount, the loan purpose. This is the default. |
| Per applicant | One per applicant on the deal | The applicant it belongs to (or a staff member on their behalf) | Anything personal: identity, income, employment, personal details. |
| Per household | One per household — shared between the primary applicant and co-applicants, but not guarantors or unrelated parties | Any household member | Joint household data in multi-family lending: shared living expenses, household assets. |
Scope applies to Form, Live Document, Signing Package, Quick Capture, and Outstanding Documents items.
Example. A deal has three applicants: Jane (Primary), John (Co-Applicant), and Pat (Guarantor).
- A Shared "Loan Details" form: one submission, owned by the deal — Jane, John, and Pat all see the same one.
- A Per applicant "Personal Details" form: three submissions — one for Jane, one for John, one for Pat.
- A Per household "Living Expenses" form: one submission shared by Jane and John; Pat (a guarantor) has no copy.
Cardinality
Cardinality answers a different question: how many instances of this item are allowed or required? Every item that supports cardinality has a minimum and a maximum number of instances.
- The minimum is how many must exist before the deal can proceed. A minimum of 0 makes the item fully optional.
- The maximum is the upper limit on how many can be added. A maximum of 0 means unlimited — there is no ceiling.
The deal shows progress relative to these limits:
| State shown on the deal | Meaning |
|---|---|
| Optional | Minimum is 0 — the item does not have to be added at all. |
| Add at least N | Fewer than the minimum have been added. |
| Maximum reached | The maximum has been hit — no more can be added. |
Scope and cardinality compose. A Per applicant item with a minimum of 2 means each applicant must have at least two instances — not two instances across the whole deal. Think "per scope unit, then this many per unit."
The same idea applies elsewhere
Cardinality is not only an item-level setting — the same min/max pattern appears in three other places:
- Repeatable sub-forms. A sub-form question inside a form template can be repeated. The min and max repetitions work exactly the same way: "Add at least 2 address history entries", or "You can add up to 5 properties, or as many as you like."
- Multi-Choice questions. The minimum and maximum number of options a user may select. Set min 2 and max 3 and the question requires the user to pick between two and three answers.
- Applicant roles. Each applicant role (Primary, Co-Applicant, Guarantor…) on the workflow has a minimum and maximum count. If the minimum for "Primary" is 1, the deal cannot proceed without one. If the maximum for "Guarantor" is 3, the broker cannot add a fourth.
Relations
Relations describe how pieces of data point at each other — how a form inside a form works, how a question can reference a field defined elsewhere, and when those references can break.
Sub-forms
A sub-form embeds one form template inside another as a question. The sub-form appears as a section the user fills out, and it can be repeatable (adding multiple entries — for example, multiple employers or multiple properties).
The parent form and the embedded sub-form are linked by reference: if you delete the sub-form template, the parent form shows a broken-reference warning and that section stops rendering.
Linked Record questions
A Linked Record question links to a record produced by another form on the same deal. For example, a "Which property is this loan for?" question might link to a submission from the "Property Details" form on the same deal, letting the user pick from the properties already entered rather than re-entering them.
Field references across forms
A field can reference a field on another form template. This is used in two ways:
- Rule conditions — a rule on a form field or workflow item can test the value of a field on a different form. For example, "Show this item only when the Loan Details form's 'Loan type' field equals 'Construction'."
- Aggregate sources — an Aggregate condition can sum or count a field across all instances of a form (useful for totalling income across applicants).
Broken references
If a form template, field, or item that is referenced by another is deleted, the builder flags a "broken" reference on anything that pointed to it. The workflow continues to run, but the broken reference is skipped at runtime. Broken references should be repaired promptly — the intended logic is not running while they exist.
Practical tips
- If two or more applicants share the same form data, use Shared scope. Adding a Per applicant form where Shared was intended means each applicant fills in the same information separately — duplicated effort and potentially conflicting answers.
- If you want a form to be optional but still appear on the deal, set the minimum to 0 and the maximum to 1 (or higher). The user can add it if needed, but can also leave the step without it.
- Before deleting a form template or field that is widely used, search for rule conditions and Aggregate sources that reference it. The builder warning only appears after the damage is done.
See also
- Order Workflows & Workflow Items — a full walkthrough of item types, including how scope and cardinality appear on each one.
- Show, Hide & Require Questions with Rules — how field-level rules use Aggregate sources to count sub-form instances.
