The Recall Letters That All Say the Same Name
Riverton Community Clinic has six staff and 1,200 active patients. For the annual recall letters, the office manager keeps the patient list in an Excel workbook (one row per patient, column headers in row 1, no blank rows) and merges it into a Word document containing the letter body plus the AddressBlock and GreetingLine merge fields. Two things went wrong this year. First, every printed letter shows the same patient's name and address, the one in row 2, even though the preview scrolled through all 1,200. Second, a handful of letters printed the literal guillemet-wrapped text where the address should be. The office manager also reports that the date column shows 03/04/2025 in Excel but prints as 4 March 2025 in some letters and as 46175 in others. She must now email the letter template to a colleague who uses Word on a Mac, and she wants to know whether to send the .docm file the clinic currently uses or re-save it as .docx.
1. Every letter prints the same patient's details. Identify the two most likely causes and describe the check that would confirm each.
Read the worked answer
Think about what controls how many records a merge consumes. In a Letters merge, Word normally emits one output document per record, so a single repeated record means the record set itself was narrowed or the fields are not truly linked.
Cause 1: the merge range or a filter is limiting output. The Merge dialog remembers the previous run's From/To boxes, and if someone previously merged record 1 to 1, the setting persists; likewise a filter in Edit Recipient List (for example an unticked box) silently restricts the set. Confirm by opening Edit Recipient List and reading the record count it reports, then checking the From/To values in the merge dialog before printing.
Cause 2: the data source was connected to a one-row range. If the workbook has the real list on a second sheet, or if the named range captured only header plus row 2, Word legitimately has one record. Confirm by placing the cursor in a field and pressing Shift+F9 to reveal the MERGEFIELD code and its source, then checking the connected range.
A quick discriminator: if the recipient list shows 1,200 records, the problem is the range or filter; if it shows 1, the connection is wrong.
2. Explain why the literal field text printed on some letters and why the same date column renders three different ways. What is the underlying principle?
Read the worked answer
Both symptoms share one principle: Word prints the field result, not the source application's display formatting, and it can only print a result for fields it recognises.
The literal text appears when those characters are not a live merge field: typed by hand, pasted as plain text, or placed inside a text box, frame, or header that the merge cannot populate. Toggle Alt+F9; a genuine field shows a MERGEFIELD code with a name matching the data source. Fix by deleting the typed text and reinserting the field from the Mailings tab.
The date splits because display formatting in Excel is a property of the cell, not of the value. The value transmitted is a date, and depending on the connection method Word may receive a serial number (46175), a locale-formatted string, or a date object it then formats with its own default. The merge field's format switch overrides everything downstream. Add a switch such as @ "MM/dd/yyyy" to the MERGEFIELD, or create a helper column in Excel using TEXT(A2,"mm/dd/yyyy") so the transmitted value is already the string you want. Never assume source formatting travels with the data.
3. Should the office manager send the .docm or re-save as .docx to the Mac colleague? Recommend a course of action with reasoning.
Read the worked answer
The .docm container is what preserves VBA macros and keeps the macro project available; saving to .docx discards macros, usually after a warning that users click through. So on paper, .docm is the safer send.
But portability is not only a container question. Word for Mac runs VBA yet fails on Windows-only calls: hard-coded C: paths, ActiveX controls, ODBC DSN connections, and some file-system objects. A macro that formats dates by opening a local workbook is likely to break even inside a .docm.
Best answer: test whether the macro is needed at all. If its only job is cosmetic, replace it with field switches and an Excel helper column, producing a macro-free .docx that carries no security prompts, cannot silently lose code, and opens identically on both platforms. If the macro does real work, send the .docm plus the data file and written instructions to enable macros, and have the Mac colleague run one test merge before the real print run. For a 1,200-piece mailing, the clinic should also merge to PDF locally and never ship the raw template as the production tool.