Add Sections to a Package
Creates the forms a deliverable is made of — each at a fixed position in the running order — before any field is filled.
Overview
A finished deliverable is rarely one form. An appraisal report is a main form plus a photo addendum plus a sketch plus a location map plus an engagement letter. An insurance submission is an application plus supplemental schedules plus certificates. A bid response is a cover sheet plus a scope narrative plus a pricing schedule plus whatever the solicitation demanded that week.
Each of those pieces is a section: one instance of a form inside the package, at a known position in the running order. Before anything can be filled, the sections have to exist. That used to be a person opening a folder of blank templates and dragging the right ones into a new job. This tool declares them instead — the whole set in one call, each with the position it will occupy when the parts are merged at the end.
What it does not do is invent the shape of the deliverable. Which sub-forms a package can contain, and the position each one takes, are fixed by the workflow the package belongs to. What gets settled per job is narrower: which of those sections this run's uploads justify, and how many copies of a sub-form that repeats. Re-declaring a section that already exists at the same position returns the existing one, so a later run can declare the full desired set without tracking what earlier runs created.
What It Does
| Capability | What it means for you |
|---|---|
| One call, whole set | Sections are declared together rather than added one form at a time |
| Positional ordering | Each section carries the position it occupies, and the finished package is assembled in that order |
| Repeated sub-forms | The same sub-form at two different positions is two sections — which is how repeated addenda and per-page passthrough sheets get made |
| No duplicate at a position | Re-declaring a section that already exists at the same position returns the existing one instead of creating a second |
| Safe to re-declare | What already exists is read from the package on every call, so a later run does not have to track what earlier runs created |
| Independent filling | Each section is filled by its own job, so sections fill alongside each other rather than in sequence |
When the Agent Chooses This Tool
Available in the appraisal-report and pre-bid workflows. The coating QA workflow does not have it.
Be clear about who decides what. The agent is told explicitly that it does not choose which sub-forms to create — the composition of the deliverable is written into the workflow's own instructions. In the pre-bid workflow those instructions name a single section and its position outright. In the appraisal workflow they list every sub-form with the position it takes, drawn from the catalogue registered for that package type, and what is left to the agent is narrower:
- Which of the listed sections this run justifies. A section is declared only when at least one of the inputs mapped to it is present among the uploads — a source file or an image. Empty sections are deliberately not created.
- Sections that must exist regardless. A sub-form marked as always required is declared on every run whether or not any upload maps to it, because its pages belong in the finished deliverable either way.
- How many copies of a repeating sub-form. The instructions fix the count: a set number for some, one section per page of the corresponding source document for others.
- Whether to re-declare. Declaring the full desired set again is safe, so the agent does not have to reason about what prior runs left behind.
Declaration comes before filling. The workflow puts the whole set in one call and then dispatches filling for every section — and because each fill is its own job, they run alongside each other. A section discovered to be missing after that point means a separate filling round for that section alone.
Inputs and Outputs
Takes: a list of sections to declare. Each entry names a sub-form and the position it should occupy in the running order, and may carry a label. The package itself comes from the run in progress, not from the call.
Returns: one result per entry, in the order given, each carrying the identifier of the section and of the fill job attached to it. An entry naming a sub-form that is not registered comes back marked as failed while the rest of the batch still goes through. An entry that matched a section already present at that position comes back as a success — indistinguishable, from the outside, from one that was just created.
Example
An appraiser uploads a property inspection sheet, a preliminary title report, a set of subject photos and a scanned engagement letter, and asks for a full report package.
The appraisal workflow already fixes which sub-forms the package can contain and where each one sits. What this run settles is which of them apply: every sub-form with at least one mapped upload present, plus any marked as always required. Where a sub-form repeats — a photo addendum, or a passthrough page for a scanned document — the count is set by the workflow, and for the per-page ones it follows the page count of the file being carried through.
All of those sections are declared in a single call. Each comes back with its identifier and an empty fill job attached. Nothing is filled yet.
Filling is dispatched next, one job per section, the jobs running alongside each other. Images are placed into the addendum slots. At the end the sections are merged in position order.
If the run is repeated, re-declaring the same sections returns the sections that already exist rather than a second set. A section declared at a different position, though, is a genuinely different section — which is what makes repeated addenda possible, and what makes a mistyped position an extra page rather than a no-op.
Limits
- Sections can only be created from sub-forms that are already registered. An unregistered name comes back as a failed entry, and registering a new sub-form is a setup task rather than something that happens mid-run. See /pricing for how custom form sets are built out.
- The shape of a deliverable is fixed by the workflow, not decided per job. Which sub-forms a package can contain and the position each takes are part of the workflow's own configuration; changing them is a change to the workflow.
- Creating a section does not fill it. A newly declared section is an empty form until filling runs.
- Each section is filled by its own job, and each of those jobs draws one fill credit. A ten-section package costs ten credits to fill, and running out partway through leaves the remaining sections marked failed rather than failing the package as a whole.
- A declared section is not a guaranteed page. When the package is assembled, a section that never received any content is left out unless its sub-form is marked as always required — so the set of sections declared is not necessarily the set that reaches the finished PDF.
- Position is fixed when the section is created, and nothing changes it afterwards. In the appraisal workflow, moving a section means removing it and declaring it again at the position you want; the pre-bid workflow has no removal step at all.
- Duplicate protection is judged by sub-form and position together. The same sub-form deliberately placed at two different positions is two sections, which is what makes repeated addenda possible — but it also means a mistaken second position produces a real extra section rather than being absorbed.
- The batch reports its outcome entry by entry rather than failing as a whole. If one entry fails the others still go through, so a run can carry on against an incomplete set of sections.
- This is not how uploaded files get attached. Source documents you upload are attachments the workflow reads from; sections are the forms it produces.
FAQ
What is a section in a document package?
One instance of a form inside the deliverable. A package is an ordered list of sections — a main form, an addendum, a certificate — and each one is filled by its own job before they are merged into a single PDF.
What happens if the agent adds the same section twice?
Nothing is created. A request for a section that already exists at the same position returns the existing one and reports success, which is what makes a run safe to repeat without producing duplicated forms. The result looks the same either way, though — nothing in it distinguishes a section that was found from one that was made.
Can the same form appear more than once in a package?
Yes, and it often has to — that is exactly what the position half of the duplicate check is for. How many copies to create is set by the workflow rather than worked out on the fly; for the sub-forms that repeat per page, it is one section per page of the source document being carried through.
Does the agent decide the package's contents, or do I?
Mostly neither — the workflow does. Which sub-forms a package can contain and where each one sits are part of its configuration, and the agent is instructed not to invent them. What varies per job is which of those sections the uploads justify. You can ask for a section to be dropped, and in the appraisal workflow it will be.
Can it add a form that isn't already set up in our workspace?
No. It can only create sections from sub-forms already registered for that kind of package; anything else comes back as a failed entry. Registering one is a setup step done once, after which it is available to runs of that package type.