Create One Form per Spreadsheet Row
Creates one form per chosen spreadsheet row and starts filling it from that row's values, in a single call, positioned by row number.
Overview
A whole class of paperwork is the same form repeated with different values. One inspection report per unit. One certificate per shipment. One coating record per section of a barge. One condition sheet per line item in a schedule. The data already exists in a spreadsheet somebody maintains; the work is turning 26 rows into 26 completed forms in the right order, without transposing a unit number.
This tool is that step. Given the rows chosen as real records, it creates one form per row and starts filling it from that row — created and filled in the same call, because a form per row and values per row are the same decision.
Two properties make it usable at volume. The order follows the row number, so the finished package reads in the same sequence as the source sheet and a reviewer can check them side by side. And a row that already has a form does not get a second one — re-running with the same rows fills the forms that already exist again rather than duplicating them.
What It Does
| Capability | What it means for you |
|---|---|
| One form per row | Each chosen record becomes its own form instance inside the package |
| Created and filled in one call | Each row's form is created and its fill started together, not left as an empty shell for a second pass |
| Row order preserved | Position follows the sheet row number, and the deliverable is assembled in that order |
| Re-runs refill rather than duplicate | A row that already has a form keeps it and is filled again; values a person set by hand are kept through the refill |
| Configured template | Which form to repeat and which tab to read come from the package's configuration and cannot be overridden in the call |
| Selective, not all-or-nothing | Only the rows passed in produce forms |
When the Agent Chooses This Tool
One of the three workflows can call this: coating QA. Appraisal and pre-bid packages cannot.
Within that workflow it is not a judgement call about whether to run. The instructions name the step outright: find the spreadsheet, extract its records, pick the real data rows, call this once, name the package, stop. The workflow has listed the attachments, found the workbook, and read its records before it gets here.
The judgement is which rows:
- Summary and section-title rows are left out. Every real data row is included; trailing totals, repeated header rows, section titles and rows that are obviously not records are not. Those rows come back from the read step like any other — nothing filters them — so leaving them out is a decision made by reading the values.
- A narrowing from the person running the job is applied by reading. "Only the underwater-body rows", "only entries after 5/1", "skip stripe coats" — the filter is applied against the record values, because no column is configured anywhere.
- Exclusions are reported. The run ends with one sentence saying how many pages were created and which rows were left out and why.
- A failed row is named, not retried indefinitely. The per-row results are checked, an errored row is reported in the summary, and the workflow is told not to retry it more than once.
Nothing in the workflow edits the forms after this step. Once the run stops, the forms are waited on and merged into one deliverable automatically. A package that needs a handful of different forms rather than many copies of one is a different workflow, which adds its sections individually.
Inputs and Outputs
Takes: the spreadsheet already attached to the package, and the sheet row numbers to produce. Which form to create and which tab to read come from the package's configuration and cannot be overridden in the call.
Returns: one result per row — the form created for it and that filling has started, or an error naming that row when the row is not in the sheet or the row otherwise failed. A row that already had a form is reported the same way as a new one.
Example
A marine coatings contractor has a QA package built on the workbook their inspector maintains: one row per coating application event, with the coat, dry film thickness readings, ambient conditions and the date.
The sheet comes back with ten records — eight application events, one section-title row and one totals row. Eight rows are chosen. Eight forms are created, positioned at their sheet row numbers, each filled from its own row, and the assembled deliverable reads in sheet order.
Two days later a ninth event is added and the package is re-run. All nine real rows are passed again. The eight forms that already exist keep their place and are filled again from the sheet as it now stands; the ninth is created. A thickness reading the inspector corrected by hand on one of the eight is kept through that refill — everything else on those forms is produced again. The deliverable is now nine records long.
Limits
- The package has to be configured for it. Which form to repeat and which tab holds the records are set up on the package. This is not a general "upload any spreadsheet, get forms" button; it is the engine behind a configured repeating deliverable.
- One form for the set. Every row produces the same form. A sheet where different rows need different forms is a different workflow.
- Rows past the first 300 are never offered. Reading the records returns at most 300 of them at a time while reporting the true total, and nothing in the workflow acts on the difference. On a longer sheet the remainder are never chosen and never become forms, and the run reports success.
- Positions are sheet row numbers. Inserting or re-ordering rows in the middle of the sheet changes which record each number refers to, so a re-run fills an existing form with a different row's values. Appending at the bottom keeps re-runs predictable.
- Deleting a row does not delete its form. Rows removed from the spreadsheet leave their already-created forms in the package, and those forms keep appearing in the deliverable. This workflow has no step that removes one.
- Which rows count is judged, not computed. A row read as decorative was judged. Unusual sheet layouts deserve a look at the first run's output before the volume is trusted.
FAQ
What happens if I re-run after adding rows to the spreadsheet?
Rows that already have a form keep it — nothing is duplicated — and those forms are filled again from the sheet as it now stands. Values someone set by hand are kept through the refill; everything else on them is produced again. New rows get new forms.
Do the generated forms come out in the same order as my spreadsheet?
Yes. Position follows the sheet row number, and the deliverable is assembled in that order. That makes checking the package against the source sheet a straight top-to-bottom comparison.
Does every row in my sheet become a form?
No. Forms are produced only for the rows passed in. Subtotal lines, section-title rows and rows that are not records come back from the read step like everything else — nothing filters them — so leaving them out is a decision made by reading the values, not a fixed rule. Rows with no values at all never appear as records in the first place.
Can different rows use different form templates?
Not in this step. Row-driven creation produces many copies of one configured form. A package that needs several different forms is a different workflow, which adds its sections individually.
What if I delete a row from the spreadsheet after the forms are made?
The form that row produced stays in the package and keeps appearing in the deliverable. This workflow has no step that removes one.
How many rows can this handle in one package?
As many as the read step offers. It returns at most 300 records at a time while reporting the true total, so a sheet longer than that has rows that are never offered and never produced. Below that, every chosen row is created and filled individually, so a longer sheet costs more time and produces a longer deliverable.