List Available Sub-Forms
Lists the sub-forms registered for the package being assembled, with each one's image slot count and whether it is marked required — available in the appraisal and pre-bid workflows.
Overview
A package is assembled out of parts, and a section can only be created for a part that has been registered in advance — ask for one by a name nothing has registered and the request comes back refused. So something has to establish which parts exist before anything gets built.
This is that list. For the package type being assembled it reports each available sub-form with a short label, how many image slots that form carries, whether it is marked required, and whether it carries fields that only apply when a previously completed package is being reproduced. It is read-only: nothing is created and nothing is filled.
The list is per package type, and it is data — registered ahead of the run rather than worked out during it.
What It Does
| Capability | What it means for you |
|---|---|
| Enumerates the available set | The sub-forms available for the package type being assembled come back as one list |
| Image slot counts | Each entry reports how many image slots that form carries |
| Required forms flagged | Forms marked required are flagged, and both workflows are told to create a marked form on every run whether or not the uploads call for it |
| Replication-only fields flagged | Forms carrying fields that only apply when a previously completed package is being reproduced are flagged, which is part of how the appraisal workflow picks a section's filling mode |
| Read-only | Listing changes nothing — it is the agent orienting itself, not committing to a structure |
When the Agent Chooses This Tool
Two of the three workflows can call this: appraisal packages and pre-bid packages. The coating QA workflow cannot.
Both are told to call it exactly once, in the same opening step that lists the uploads, and both are told not to call it again later in the run. Nothing carries the answer between runs either — a prior run's listing is left out of the history the agent is given, so it is fetched fresh at the start of every run.
What the workflows do with the answer:
- Composition is not decided from it. Neither workflow lets the agent choose which sub-forms to create. The appraisal instructions carry a fixed list of parts, each with a fixed position in the deliverable, and the pre-bid instructions name a single section outright. What this list contributes is the two flags, not the shape of the package.
- The required parts get declared regardless. Both workflows carry the same exception in as many words: a sub-form marked required is declared on every run, whatever the uploads look like. The appraisal instructions note that such a part often has no field data to fill at all — the certification page is there to hold its place in the deliverable.
- The filling mode follows the replication flag. In the appraisal workflow, a part flagged as carrying replication-only fields is filled differently depending on whether this run brought in that part's own copy out of a previously completed package — usually made available section by section via Split a Filled Package. The pre-bid workflow fills its one section the same way every time.
- The image work happens per slot. Sections are created with Add Sections to a Package, and images go in one slot at a time with Place an Image in a Slot.
Inputs and Outputs
Takes: nothing. It reports on the package the run is already working on.
Returns: one entry per available sub-form — a short label, how many image slots it carries, whether it is marked required, and whether it carries fields that only apply when a prior completed package is being reproduced.
Example
An appraiser's packet arrives: subject and comparable tax records, a comparables spreadsheet, an MLS export, a notes file, and a multi-page location map exported as a PDF.
In its opening step the agent lists the uploads and lists the sub-forms available for this package type. Back comes one entry per available sub-form: a short label, how many image slots that form carries, whether it is marked required, and whether it carries fields that only apply when a previously completed package is being reproduced. Parts registered for other package types are not in the answer, and neither are the registered parts this list is set to leave out.
Two things in that answer change what happens next. A part that comes back marked required is declared whether or not anything in the packet fills it — its pages belong in the deliverable either way. And a part that comes back carrying image slots is a separate placement call for each of them later, one slot at a time.
The agent then commits the subject property facts, declares the run's sections in one call, and dispatches filling. It does not list the sub-forms again.
Limits
- Read-only. Listing creates nothing; sections are created separately.
- This list is not the enforcement boundary. It is filtered to the package type being assembled, and some registered parts are deliberately kept out of it; creating a section is refused only when the name is registered nowhere at all. A part this list omits can still be sectioned in if something asks for it by name.
- Slot counts describe capacity, not content. A form reports its registered image slots whether or not any images have been placed in them.
- "Required" reflects how the package type was registered, not an agency's compliance checklist. It is a useful default, not a guarantee that a recipient will accept the package.
- This is an inventory, not a field map. Entries carry a short label rather than a description of what the form is for, and nothing about what the fields on it are called — field-level detail comes from Extract Form Fields.
- The answer is scoped to the package type being assembled, so it is only valid for that package.
Set Up Per Package Type
The content of this list is data, not code. Which parts a package type offers, and how many image slots each of them carries, is registered before any run happens; the tool reports whatever is registered. Building that set out — the templates and their image slots, and which of them are marked required — is implementation work, described on /pricing.
Once it exists, both workflows read it at the start of every run, and no part that has never been registered can be sectioned into a package. See /solutions/real-estate-appraisal for the workflow these parts were first built for.
FAQ
What is a sub-form?
One of the form templates a package type can be built from — a main report form, a photo addendum, a certification page, a continuation sheet. A package is an ordered set of sections, and each section is one instance of a sub-form at one position.
Can the agent use a form that isn't in the catalog?
It cannot invent one: creating a section for a name nothing has registered comes back refused. But this list is a narrower thing than that boundary. It is filtered to the package type being assembled and some registered parts are deliberately kept out of it, while section creation accepts any registered name. And a newly registered part is not built simply because it now appears here — what each workflow assembles is fixed in its own instructions.
What are replication-only fields?
Fields whose authoritative values come from a previously completed package rather than from this run's source documents. When the appraisal workflow is reproducing such a package, the run that brings in a part's own prior copy writes only those fields; a later run that refills the same part from new sources writes everything except them, so the carried-forward values survive. The flag in this list is how the agent knows which parts have them.
Do all customers see the same sub-forms?
For the same package type, yes. The list is scoped to the package type being assembled and to nothing else, so two packages of the same type get the same set. Different package types get different sets, which is what the scoping is for.
Does listing sub-forms change the package?
No. It is a read-only look at what is available. Creating sections, and deciding their order, is a separate step the agent takes afterwards.