Personalised Letter Batches: Which Record Belongs in Each Recipient's Document?

A customer list and a letter template are not yet a reliable document-generation workflow. Before commissioning a mail-merge feature in a business app, decide what one output represents, which records are included and how staff verify that each recipient receives only the intended content. A well-formatted first page does not establish that the rest of the batch is correct.

This is particularly useful when a small team prepares individual renewal letters, account notices or appointment instructions for printing. Start with the documents and the recipient relationship, not with a request to add an export button. The recommendations below concern document preparation. They do not establish permission to send marketing, legal sufficiency of a notice or successful postal delivery.

Define the unit of correspondence

In a fictional example, a service business wants one renewal letter for each customer agreement. A customer with two agreements might need two letters or one combined letter. Neither answer can be inferred simply from the customer's name. Write down the intended rule before selecting a data source.

Keep a stable agreement reference alongside the recipient identity. If several rows describe items belonging to one agreement, decide whether they should appear as a table inside one letter rather than produce several copies of the same greeting. Conversely, two customers sharing a postal address should not automatically be combined into a household document.

Ask the developer to demonstrate the relationship using invented records. A correct total number of files can conceal an incorrect allocation of details between people.

Select records deliberately

The official LibreOffice Mail Merge documentation, retrieved as LibreOffice 26.8 Help, describes replacing database placeholders with database information. Its Records section distinguishes all records, previously marked selected records and a first-to-last record range. It states that one letter is printed for each record.

That is a concrete product example, not a promise that a custom app already groups agreements or understands customer eligibility. The business must still define what its input record means. Do not assume that selecting a customer on one screen selects all or only the appropriate agreements on another.

Require an inspectable inclusion list for the proposed batch. Show the business reference, intended recipient and reason for inclusion. Decide whether changes to an agreement after preview invalidate that preview or remain outside a deliberately frozen batch. Avoid an unexplained change in membership between approval and generation.

Review merged values, not just the template

A template with a name placeholder can look excellent while producing a poor actual letter. Use synthetic examples with long names, missing optional details, different address lengths and more than one agreement. Check the actual rendered document, including page breaks and any information near the address window.

Specify a rule for required missing values. The workflow might hold the affected letter for correction while allowing reviewed letters to proceed. It should not silently borrow a value from the previous record or produce an apparently complete notice containing an unresolved placeholder. These are proposed acceptance requirements, not documented LibreOffice validation features.

Distinguish a business reference from a positional record number. Sorting or filtering a list should not leave staff identifying a customer solely as “record seven”. Give reviewers enough information to connect each generated output to its intended source without unnecessarily exposing private data in filenames.

A combined print file is not an individual customer file

The same LibreOffice page documents printer output and file output. For files, it distinguishes one large document containing the records from individual documents, one per data record. It also describes generating filenames from a database field.

Choose the output deliberately. A combined document may suit a controlled print run. It is not automatically suitable for attaching to an individual customer's portal record. For separate files, agree how duplicates and empty filename values are handled, and retain a clear output-to-business-reference mapping. A filename alone is not an access-control rule.

Define what a correction creates. If one letter is regenerated, the team should be able to identify the replaced output and avoid printing both versions accidentally. Keep generation, review approval and physical dispatch distinguishable. A saved file is evidence of preparation, not evidence that an envelope was sent or delivered.

Accept the recipient mapping with the finished output

At acceptance, run a small synthetic batch containing two agreements for one customer, two unrelated people at one address, a missing required value and a letter that spans more than one page. Compare every output with the inclusion list. Demonstrate the chosen combined or individual format and a corrected reprint without treating the whole batch as new correspondence.

Bring those examples to the web-app project discussion. The useful deliverable is not simply faster letter production. It is an explainable connection between the approved recipient set, the exact generated content and the document the team actually uses.