Plenty of documents cannot be generated from one person's answers. An insurance application needs the agent's section and the insured's section. A lease needs the landlord, the tenant, and sometimes a guarantor. A new hire packet needs the employee's data plus whoever approves the hire. The document only exists once every party has done their part, so you need somewhere to hold partial data and some way to know when it is complete.
Pattern 1: one form, one submitter
Have one person gather everything and type it in. For low volume this is often the right call, and it needs no new infrastructure. It breaks as soon as a party holds information the submitter does not have, or should not see, and it concentrates every transcription error on one person.
Pattern 2: sequential forms against a shared record
Create the record first, then give each party a URL scoped to their own section. Party one submits, the record advances, party two gets notified. Each URL renders only the fields that party owns, so nobody sees anyone else's data. Most real workflows converge on this.
Two things to get right. Give the record an explicit status (awaiting_agent, awaiting_insured, ready_to_generate) rather than inferring completeness from which columns are non-null, because that inference breaks the first time a field is legitimately blank. And make each party's URL a single-use, unguessable token instead of a sequential record ID, since you are handing it to someone outside your system.
Pattern 3: parallel sections with a join step
When parties do not depend on each other, send every invitation at once and generate the document when the last section lands. Faster in wall-clock time, more bookkeeping: you need per-section completion flags and a check on every submission asking whether the set is now complete. Two sections submitting within the same second will both see themselves as the last one, so make that check idempotent or guard it with a lock or a unique constraint on the generated document.
What bites regardless of pattern
Validate per section, not only at generation time. Discovering a malformed date of birth at the end means reopening a form someone already considers finished. Decide up front what happens when a party never responds: an expiry, a reminder schedule, and a way for a human to reassign or fill in on their behalf. And keep the collected data separate from the generated file. The document is a rendering of the record at a point in time, so regenerating it should be cheap and repeatable rather than a destructive edit.
If you would rather not build the record, the tokens, and the state machine yourself, this is a well-trodden enough problem that document platforms handle it directly. Anvil's Workflows, for one, include multi-party data collection, where you configure a separate webform or signature step per party and the documents generate once the sections are in. It is available on their free plan.
Back to All Questions