Recruiter-Proof Offer Packet
HR issues an offer packet: a two-page letter, a benefits summary and an acknowledgement page. About 30 recruiters build roughly 90 packets a month. Legal requires that the candidate name, job title, start date and salary band appear in the body and the footer of every page; that recruiters cannot reword boilerplate; and that the salary band be chosen from a fixed list of six values. Recruiters currently copy last month's letter, and last quarter six offers went out with a stale start date sitting in the footer. Files are versioned by renaming: Offer_JSmith_final_v3_ACTUAL.docx.
1. Design the fields so that a value typed once appears in the body and the footer, and so the salary band cannot be mistyped.
Read the worked answer
Typing into two content controls does not link them - that is the bug that produced the stale footer. Build a single source of truth instead:
- Custom document properties for CandidateName, JobTitle, StartDate, SalaryBand (File > Info > Properties > Advanced Properties > Custom).
- Insert them as Quick Parts > Document Property controls in the body, and insert
{ DOCPROPERTY SalaryBand }fields (or the same property control) in the footer. Editing the value anywhere updates every occurrence, footer included, because they all read the property rather than holding their own text. - For the closed list, use a Drop-Down List Content Control bound to the property, or a
{ DOCPROPERTY }field next to a dropdown whose entries are the six legal bands - recall is impossible when the only options are the six.
Judgement calls: use a Date Picker content control for StartDate (its stored value is a real date, so { DOCPROPERTY StartDate \@ "d MMMM yyyy" } formats reliably; a plain text control gives you whatever the recruiter typed). Set Content control properties > Content control cannot be deleted on the boilerplate blocks so a stray Ctrl+A Delete cannot wipe the legal text, and keep a named custom property for the packet version.
2. How do you stop recruiters rewording the boilerplate while still letting them fill the fields, and what does that protection not achieve?
Read the worked answer
Two layers, because they block different things:
- Developer > Restrict Editing > Filling in forms. This locks everything except form fields and content controls; body text and the acknowledgement wording become read-only. Enforce with a password - unticked enforcement is a suggestion, not a restriction.
- Limit formatting to a selection of styles in the same pane, so a permitted edit cannot restyle a locked paragraph into something legal never approved.
What it does not achieve:
- It is a productivity guard, not security. Anyone can save a copy, remove the restriction, and edit; Word's protection is not encryption.
- It does not stop copy-paste of the packet into a new blank document.
- It does not fix version sprawl. For that, store the packet as a template in a SharePoint library and have recruiters use New from template, so each offer is a new file and version history replaces the filename convention.
If the packet leaves the organisation, issue a PDF for the recipient and keep the protected .docx internally. Restriction plus a password protects the process; only a PDF protects the output.
3. The benefits summary and acknowledgement page are identical in every packet. How do you package them so a recruiter can drop them in without editing them, and what risk do you accept?
Read the worked answer
Use reusable content rather than retyping:
- Save each fixed block as a Building Block (select it, Insert > Quick Parts > Save Selection to Quick Part Gallery), stored in a template so it is distributed rather than local to one recruiter's Normal.dotm. Inserting it takes two clicks and the content arrives consistent.
- Alternatively build the whole packet as one template with the fixed pages already in place and locked content controls in the variable areas - usually the better answer here, because 90 packets a month of two-page letters does not need a gallery at all.
Risks to accept and mitigate:
- Building blocks live in a specific template file. If it is not distributed (or Normal.dotm is reset), recruiters 'lose' the blocks and go back to copy-paste. Ship it as a shared template and add the location to Trust Center trusted locations.
- Once inserted, a building block is ordinary content - the recruiter can edit it. Locking only works on content controls; if the benefits summary must stay untouched, make it a locked content control inside the template, not a building block that arrives unlocked.