Fill a Form for Every Spreadsheet Row

Fills the same form once for every data row of a spreadsheet attached to the package, as one batch, and delivers the filled rows merged into one PDF.

Overview

A lot of paperwork is one form repeated for a list of records: a claim per patient, a certificate per shipment, a notice per tenant. The records already sit in a spreadsheet, and filling them one run at a time means one run per row.

This tool fills the whole list in one call. Every data row of the spreadsheet gets its own copy of the form to fill, inside a batch built the same way as a batch you create yourself with batch form filling. When the run ends, the package's deliverable is the filled rows merged into one PDF, and the agent is given a link to the batch.

What It Does

When the Agent Chooses This Tool

Available in the Fill Any Form workflow. The appraisal-report, pre-bid and coating QA workflows do not have it.

The workflow's instructions send the agent here instead of the ordinary fill when the data is a spreadsheet attachment (.xlsx, .xlsm, .xls or .csv) whose rows are two or more separate records for the form. The call takes the same form and the same typed messages the ordinary fill would have taken, plus the spreadsheet.

• A single row, or data that is not such a table goes to the ordinary fill instead.
• A spreadsheet that could go either way is put to you as a question with two options: one filled form per row, or one filled form from the whole spreadsheet.
• The form is either one the run added from the package's attachments or one from your forms library.
• One batch per run. The instructions allow at most one ordinary fill or one batch in a run, and a second batch in the same run is refused before anything is reserved.

Inputs and Outputs

Takes: the form, the spreadsheet attachment from this package, and which of your typed messages apply to every row.

Returns: how many rows were filled, the numbers of the rows that failed, the numbers of the rows still filling when the wait ran out, and a link to the batch. A refusal returns its reason instead.

Example

A billing team adds a blank claim form and a spreadsheet export with one patient per row, two rows in all, and types "Use the Brooklyn office address."

The agent reads the export as two separate records and fills a batch. Two batch fill credits are reserved, and each row's fill is given that row's values and the typed instruction. When both rows are done the agent has a count of two filled rows and a link to the batch, and the package's deliverable is one PDF holding both claims, first row first.

Limits

• Only the first sheet of a workbook is read. Any other tab is ignored.
• The column names are looked for in the first two rows. A table whose header sits lower down is read with the wrong header.
• Rows fill from the spreadsheet and your typed text. Other documents attached to the package do not reach a row's fill.
• Batch fill credits only. Each row reserves one batch fill credit, and the ordinary fill credits are not drawn on. When there are too few, no batch starts and the agent is told how many were required and how many were available.
• A failed row's credit goes back.
• The wait for rows has a limit. Rows still filling when it runs out are reported as still generating and are not stopped. The merged PDF holds only the rows that had finished when the run assembled it.
• A form still fine-tuning when its wait runs out gets nothing filled.
• A run in which no row was filled fails, and the run's own credits go back.

FAQ