Version 3 removes one candidate, corrects another candidate’s notice period and adds a new compensation expectation. The client opens Version 1 from an old email and calls the removed candidate directly. Everyone had the latest shortlist. Just not the same latest shortlist.
How should agencies control shortlist versions?
Keep one canonical shortlist record linked to candidate-specific source facts, approvals and a numbered release history. Every client release should identify its version, timestamp, recipients, changes and status, while superseded portal views and links are clearly withdrawn or marked obsolete.
Version control is not file naming alone. A credible workflow connects each summary to the underlying CV and recruiter evidence, shows who approved a change, records what the client actually received and prevents a corrected fact from coexisting silently with an older presentation.
Do not rewrite history. Preserve the released version and correction trail with proportionate access, then make the current version unmistakable. The objective is accurate decisions and candidate trust, not a perfect folder full of “FINAL_v7” documents.
Choose one canonical shortlist and one release owner
The ATS or controlled client workspace should hold the current decision set, not a consultant’s attachment folder.
Name the mandate owner who can publish a version. Researchers and consultants can propose edits, but the release owner checks candidate approval, client scope and factual changes before presentation. Without that gate, two well-meaning colleagues can send competing updates within minutes.
Separate the live shortlist from working longlists. A candidate under research, a candidate approved for presentation and a profile released to the client are different states. One “shortlisted” checkbox hides the very transitions the team later needs to prove.
Give each release an immutable identifier, human-readable date and status: current, superseded, withdrawn or draft. A timestamp alone is weak when team members work across time zones or rebuild documents from cached data.
- Mandate and release identifier.
- Named publisher and approval timestamp.
- Included candidate record versions.
- Recipients, channel and current or superseded status.
Version candidate facts before composing the client narrative
The shortlist should reference source-backed candidate facts rather than duplicate them into uncontrolled prose.
Link the presentation to the CV version, interview note, compensation confirmation, availability check and candidate-specific restrictions used at release time. If the source changes later, the system should show which old release relied on the earlier fact rather than silently rewriting what the client saw.
Distinguish facts from recruiter assessment. “Available from 1 November” needs a confirmation date and source. “Strong stakeholder presence” is an assessment that should cite the observed interview evidence. Blending both into a polished paragraph makes later correction harder.
Ask candidates to review material facts where appropriate before identifiable submission. Approval for one company and one profile version should not become blanket permission for every later presentation. Record boundaries, not just a green tick.
Use a change log that explains consequence, not typography
Record changes that can affect a decision, candidate expectation or disclosure.
Useful change categories include candidate added or removed, role requirement changed, CV replaced, compensation corrected, notice period revalidated, location constraint updated and assessment amended. Ignore harmless formatting changes unless they alter meaning. The client needs signal, not a novel about font size.
For every material change, record who requested it, the evidence, who approved it and which recipients need an update. If a candidate withdraws, use the withdrawal workflow as well as the version log; simply deleting the row leaves old exports actionable.
Never edit a released PDF in place. Create a new release and mark the prior one obsolete. This preserves the decision context without presenting stale data as current.
A change log should answer “what decision could this alter?” If it cannot, it is probably noise.
Make the current version obvious in every client channel
Portal, email and meeting materials should point back to the same release state.
Prefer a candidate-aware client portal where the current status is visible and access can be revoked. If attachments are necessary, put the release identifier and generated time inside the document, not only in the filename. Forwarding strips email context quickly.
When a version is superseded, notify the named recipients with the specific change and required action. “Please see updated shortlist” is too vague when one candidate must no longer be contacted. State which file is obsolete and whether already scheduled activity changes.
Do not claim that a portal update recalls downloaded documents. Track known downloads, ask the client owner to replace copies and capture confirmation. Technical truth builds better controls than wishful language.
Handle corrections as a propagation task
Correct the source, identify every dependent release and tell affected decision-makers what changed.
A candidate may correct a job title, salary expectation, notice period or reason for leaving. Validate scope and update the canonical record without erasing the earlier source. Then find shortlists, reports, scorecards and client notes that repeat the wrong fact.
Prioritise corrections that can affect an active decision. Send a concise notice that states the corrected fact and replaces the old version; do not expose the candidate’s frustration or speculate about blame. If the error came from parsing or manual transcription, record that cause for prevention.
Where a correction is disputed, mark the fact as under review and keep the candidate’s statement visible to authorised reviewers. A binary overwrite can make a genuine disagreement disappear.
- Correct or annotate the canonical candidate field with source and time.
- Locate releases and recipients that used the earlier value.
- Publish a replacement or correction notice with clear consequence.
- Confirm client action and repair the process that caused the error.
Control exports, printouts and meeting decks
Every offline copy needs an owner, purpose and route back to the current shortlist.
Board searches often move into decks and committee packs. Put the release ID, confidentiality label and current-status link on each page where practical. Ask the client secretariat how papers are replaced after correction and who receives them.
Limit broad spreadsheet exports. A decision table may need criteria and candidate evidence but not the entire CRM profile or years of contact history. Generate the smallest useful view for the named audience and close access after the decision window.
At mandate closure, inventory final releases and unresolved copies. Apply the agreed retention and disposal decisions by category. Leaving every “final” deck in a shared folder indefinitely is not version control.
Audit whether people can reconstruct a real decision
Sample one placement and one rejection to test the release history end to end.
Can the team show the brief version, candidate evidence, approval, release, client recipients, later corrections and final outcome? If the answer depends on one consultant’s inbox, the system has not captured the decision trail.
Measure superseded files still accessible, releases without candidate approval, corrections without client confirmation and current shortlists built from stale facts. These metrics reveal risk and wasted work better than counting how many PDFs the team produced.
Keep governance proportionate. A two-person agency does not need enterprise document bureaucracy. It does need one current record, clear ownership, material change history and a way to stop stale information driving client action.
Shortlist release record
A compact release record makes the current shortlist clear while preserving the evidence behind earlier client decisions.
| Release field | What to capture | Why it matters |
|---|---|---|
| Identity | Mandate, release number, publisher and timestamp | Creates one reference for every channel |
| Candidate inputs | CV, fact checks, assessment and approval versions | Shows what supported the presentation |
| Recipients | Named users, email addresses, portal and downloads | Defines the correction audience |
| Changes | Material change, source, approver and consequence | Separates decision updates from formatting |
| Status | Draft, current, superseded or withdrawn | Prevents stale versions appearing active |
| Closure | Final copy, retention decision and outstanding copies | Stops old packs remaining indefinitely |
What version control cannot recover
A new portal release cannot technically recall every attachment, printout or forwarded deck. The agency still needs a known-recipient process, explicit correction and client confirmation.
A complete release trail does not make an inaccurate or excessive assessment appropriate. Candidate facts, evaluation criteria, disclosure purpose and access still need separate human review.
Shortlist version-control questions
These answers deal with the practical failures that appear when ATS records, email attachments and client decisions diverge.
Should every shortlist edit create a new version?
Create a new release for material changes that affect candidate inclusion, facts, assessment, permission or client action. Harmless formatting can remain an internal edit if meaning and recipients do not change.
Can the ATS overwrite an incorrect candidate field?
Correct the current field, but preserve source and change history where needed. Identify released documents that used the old value and propagate the correction rather than relying on the updated profile alone.
Is a client portal enough to prevent stale copies?
It makes current status and revocation easier, but clients may download or copy information. Track known exports, label releases and use a recipient-confirmation process for material corrections or withdrawals.
Who should own shortlist publication?
Name one mandate release owner with authority to verify candidate approval, factual evidence and recipient scope. Contributors can propose changes; a clear gate prevents competing client versions.
Official sources for accurate, controlled candidate records
These sources explain accuracy, data minimisation, secure access and recruitment-record responsibilities that support a controlled shortlist process.
- EUR-Lex: General Data Protection Regulation — rights, accuracy, storage limitation and security
- UK Information Commissioner’s Office: Recruitment and selection data-protection guidance, currently identified as draft
- European Data Protection Board: Secure personal data and review access authorisations
Build a cleaner client-submission process
Record candidate submission approval · Manage candidate withdrawal everywhere · Review client-portal access · Explore Yena’s client portal
Give the client one current shortlist
Yena connects candidate evidence, approvals, client access and mandate history so consultants can update a shortlist without losing the decision trail behind it.
Explore the client portal