The Template That Keeps Breaking
A consultancy built a proposal template (.dotx) with a branded cover, a styled body, and a footer containing the client name. Staff report that when they open the template and save, the file becomes a .docx - fine - but the footer still shows the previous client's name, and the cover page date is frozen at the date the template was created. Separately, a manager edited the template's Heading 1 style (changed it to green) and saved; new documents now start green, but 30 existing proposals did not change. The firm wants new proposals to auto-fill the current date and client name, and wants style changes to propagate predictably.
1. Why does the footer keep the old client name and the cover date stay frozen, and what should replace those fixed values?
Read the worked answer
Both are static text typed into the template. A template only supplies starting content; typed text is copied verbatim into each new document and never updates.
Replace with fields:
- Cover date โ a Date field (or a field set to update on open/print), so it reflects the current date rather than the creation date.
- Client name โ a document property field (e.g. a custom document property such as
ClientName), or a content control bound to that property, so the author fills it once and it appears in the footer and body consistently.
Key distinction to state: static text is frozen at authoring time; a field is evaluated when the document is opened, updated, or printed. The symptom (old client name, frozen date) is the signature of static text where a field was needed.
2. The manager's Heading 1 change affected new documents but not the 30 existing ones. Explain why, and state whether this is correct behaviour.
Read the worked answer
Why: The 30 existing proposals were created from the template, so they carry their own copy of the style definitions. Editing the template's style updates the template only; documents already created do not inherit later template edits. New documents pick up the green Heading 1 because they are generated from the edited template.
Is it correct? Yes - this is expected behaviour, not a bug. A template is a starting point, not a live link.
What to do about the 30 files: If they must match, either (a) open each and use the Organizer / style tools to copy the updated style from the template, or (b) apply the template's styles to existing documents, or (c) re-base them on the template. There is no automatic retro-update, so the expectation must be set with the manager: template edits propagate forward, not backward.