Generating documents
How a package of documents is generated from a file matter: checking what each document will say, filling shared values, choosing between separate files and one merged document, and how revisions are recorded.
Where generation happens
Open a file matter and go to its Documents tab. The Templates view generates one document at a time; the Packages view generates a named group of documents together. The History view lists every past run and can repeat one with the same documents.
When there is no package for this file
The Packages view lists the packages an administrator has configured for this file's type. When none fits — or none exists — the last row, Custom package, lets you choose documents for this file yourself. Choose… opens a picker with one row per document name and that name's used for variants beside it. Tick variants, or filter by used for and take everything shown; your picks collect on the right. Continue opens the ordinary generate dialog with them, where you can drag the rows into the order they should generate in and Add document opens the same picker.
A custom package is recorded in the file's History as Custom package, numbered per file, and can be generated again from there like any other run. It is kept nowhere else: no package is created, nothing is added to the Templates page, and no other file sees it. To make a set available to every file of a type, ask an administrator to configure it under Templates → Document → Packages.
The generate dialog
Clicking Generate on a package opens a preview before anything is produced. The left side is an index of the run's documents; the right side is a reading pane showing what the selected document will actually say, resolved against this file matter: every value, every table row of a repeating section, and the signature block drawn as it will print.
- Ticking a document includes it in the run. A package does not have to be generated whole, and anything from the library can join a run with Add document (the package itself is unchanged).
- Clicking a row opens that document in the reading pane. A row's second line shows its code and whether it is ready or will have blanks.
What gets ticked
A document in a package can carry a rule saying when the package proposes it, set on the Templates page under the document's row in the package. When you open Generate package on a file, the rules are read against that file and only the documents it calls for start ticked.
- Each row with a rule says why in one line — Suggested — any guarantor's Independent legal advice is Required, or Left out — only when …. A document with no rule is always suggested and says nothing.
- Nothing is binding. Tick or untick anything; a left-out document resolves as soon as it is ticked. Reset to suggested appears beside Select all once the ticks differ, and puts them back.
- A run that differs from what was suggested is recorded in History as modified — measured against what the window proposed, not against the whole package.
- Repeating a run from History reopens it on the documents that run contained, without proposing anything: a repeat is meant to reproduce what happened.
Shared values
Values that are typed at generation time (rather than read from the file matter) are shared across the run: an input two documents use is typed once. They live under Shared values at the top of the index, each one naming the documents it feeds. Typed values are remembered per file, so the next generation prefills them.
When something will be blank
A strip appears under the header only when a value will be blank, and it splits the blanks by who can fix them. A missing shared value is a chip: clicking it opens the field, ready to type. A field the file matter never set is counted but not clickable, because it is fixed on the file matter, not here. Blanks never block a run, but the dialog asks once before generating with them.
Separate files or one document
- Separate files: each document is its own .docx, downloaded together as one archive. Each document can be given its own file name in its reading pane, and each name carries the revision the document will be on (for example
Transfer_R03.docx). - One document: the run comes out as a single merged .docx, named in the dialog header. Each document keeps its own formatting, headers, footers and fonts, starts on a new page, and restarts its page numbering, so a "Page X of Y" footer counts pages within that document.
What order decides
In one-document mode the index gains a numbered spine and drag handles: the list order is the order the documents appear in the merged file, and dragging a row moves its document. Order decides sequence only. A document reads the same in position four as in position one, because its own fonts, spacing and styles travel with it. The document at position one also supplies document‑wide settings such as compatibility options, which is rarely something to think about.
Revisions
Each document's reading pane has a Revision control with two named outcomes: New creates the next revision when values changed, and Overwrite keeps the document on its current revision and rewrites that entry's values (useful for a typo fix that should not count as a new revision). Values stamped in by the run, such as the generation date and the footnote, never count as a change on their own. A first generation is always saved as R01. This applies per document, in both formats: a merged file records a revision for each document inside it.
After a run, the dialog stays open on a result screen listing what happened to each document, and the run is recorded in History, where it can be downloaded again or repeated with the same documents.
Limits of the merged format
Text, tables, images, footnotes, numbering and hyperlinks all carry into a merged document. Charts, embedded objects (OLE) and SmartArt do not: if a template contains one, its text and images still come through, but that object may not. Generate such a package as separate files instead.