Set a narrow handover boundary
Use this suggested workflow practice only after the custom system, relevant business record, attachment capability, and intended handover release are already scoped. The purpose is to agree how one attachment replacement will be demonstrated and recorded. The deliverable is an attachment-version acceptance worksheet, not a broad statement that every uploaded file is permanently traceable.
Start with the dated scope or release reference, the record type being reviewed, and the existing role already permitted to replace an attachment. Name the business record by its stable test reference. State the question in observable language: when an authorised role replaces an attachment, can the reviewer distinguish the visible current file from the earlier file within the agreed capability?
Keep this review separate from archive search, portable exports, backup restoration, concurrent field edits, access-policy design, generic UAT, or a request for new screens and controls. A useful question can expose a gap, but it does not automatically add that gap to the release. Record the gap and route it through the agreed scope-decision process.
- Use synthetic documents only
- Name the agreed release
- Link one business record
- Confirm replacing role
Agree the evidence before testing
Prepare two harmless synthetic documents. Give them the same displayed filename, such as service-note.pdf, while making their contents clearly different. Put an obvious version reference inside each file, for example Synthetic version A and Synthetic version B. The matching name tests whether reviewers rely on a filename instead of evidence that identifies the file itself.
Before any upload, agree what the worksheet will capture: original upload reference, proposed replacement reference, displayed filename, linked record reference, actor role, visible current-version result, earlier-version result where available, retrieval actions, reviewer, and decision. A version reference may be a system-provided identifier, a visible revision label, or another agreed observable distinction. Do not invent a technical identifier that the product does not show.
Describe acceptance outcomes as checks, not assumptions. GOV.UK guidance supports using observable acceptance criteria to confirm whether a user need has been met. Here, the worksheet is suggested practice: it adapts that principle to a bounded handover review and does not impose a product design.
- Prepare two different contents
- Match displayed filenames
- Record each version reference
- Agree observable outcomes
Run one controlled replacement
Use an isolated non-production environment and the agreed authorised test account. First upload the synthetic original to the named business record. Capture the displayed filename, its version reference or distinguishing evidence, the record link, and any visible upload state. Confirm that the worksheet describes what was observed, rather than what the team expects the underlying storage to do.
Then have the already agreed replacing role submit the proposed replacement with the same displayed filename. Do not alter permissions, change retention settings, or use a customer, staff, payment, or live operational document to make the test work. The aim is a repeatable demonstration of existing scope, not a simulation of every possible file event.
Open the record again using the normal agreed retrieval route. Identify which attachment is presented as current. If the product presents a prior version, open or otherwise retrieve it through the agreed route and compare the visible distinguishing evidence. Record actions and results precisely. If the product only presents the current attachment, record that fact without inferring that an earlier version exists elsewhere.
- Use a test environment
- Upload original first
- Replace under agreed role
- Retrieve through normal route
Check contents, not just names
Matching filenames alone do not prove matching contents, identity, or replacement history. A reviewer should open the current file and verify its embedded synthetic version reference. Where an earlier version is visibly available within scope, open that file too and verify its different embedded reference. The worksheet should say what was read or displayed, not merely that two files appeared in a list.
Also confirm that the displayed current attachment remains linked to the correct synthetic business record. This avoids accepting a technically distinct file that has been associated with the wrong job, customer, task, or other record. Record the stable record reference and the retrieval path used by the reviewer.
Do not turn a failed distinction into a claim about immutability, deletion, retention, or hidden system logs. The test can only support what reviewers observed in the agreed environment. If a file preview is unavailable, record another agreed safe method for observing the embedded reference, or mark the content comparison as not completed and explain why.
- Open the current document
- Read embedded reference
- Check linked record
- State unobserved facts
Decide exceptions honestly
Use three simple outcomes. Accept means the agreed current version, linked record, and required evidence were observed. Accept with limitation means the current version and record link were observed, but the system did not retain or expose an earlier version within agreed scope; write that limitation plainly. Hold for decision means an agreed observable check could not be completed, evidence conflicted, or the role could not perform the scoped action.
An unavailable earlier version is not automatically a defect. First compare it with the dated agreed scope. If historical-version retention was never agreed, record that the worksheet cannot demonstrate it. The business owner or authorised scope decision-maker can then decide whether the limitation is acceptable for handover, needs clarification, or is a separate future request.
If replacement is visible but the current file cannot be matched to its synthetic embedded reference, do not accept merely because its filename is correct. Preserve the worksheet, note the failed check, assign a decision owner, and avoid changing the system during the review unless a separately approved action authorises it.
- Choose an outcome
- Record limitations plainly
- Assign decision owner
- Avoid scope expansion
Fictional worksheet example
Fictional example: On record JOB-DEMO-17, the agreed coordinator role uploads a synthetic document displayed as inspection.pdf. Its first page says Synthetic version A. The worksheet records original reference UP-041, the displayed name, the record link, and the test environment. The coordinator then replaces it with another document also displayed as inspection.pdf, whose first page says Synthetic version B and whose visible reference is UP-042.
A reviewer reopens JOB-DEMO-17 through the ordinary record view. The current attachment opens and shows Synthetic version B. A history area also shows UP-041; opening it shows Synthetic version A. The reviewer records both retrieval actions, the observed references, and an acceptance decision limited to this record, role, environment, and demonstrated route. This is fictional test evidence, not evidence about a client or every attachment.
If the history area had not appeared, the worksheet could instead record: current attachment UP-042 and Synthetic version B were observed; an earlier version was not exposed by this agreed review route; historical retention was not demonstrated. That is an honest limitation, not a reason to claim hidden recovery or require a retention period.
- Label example fictional
- Use stable test reference
- Compare embedded versions
- Limit the decision scope
Complete the reusable worksheet
Before handover, assemble one readable acceptance worksheet. Include the dated scope or release, environment, test date, synthetic record reference, replacing role, original and proposed replacement evidence, displayed filename, current-version observation, earlier-version observation or limitation, retrieval steps, reviewer, decision owner, outcome, and open actions. Keep evidence locations understandable to the people who will review the handover record.
Review the worksheet with the person authorised to accept this bounded result. Ask whether every required observation is present, whether an uncompleted check is clearly marked, and whether any request is being mistaken for an agreed requirement. A concise worksheet is stronger than a vague assertion that attachment history works.
This guide ends once the worksheet has a recorded decision and any limitation has a named next step. It does not authorise real-data uploads, change permissions, prescribe retention, certify backups, or operate a production release. Outcomes are not promised beyond the specific observation recorded.
- Complete all worksheet fields
- Name acceptance authority
- List open actions
- Keep decision bounded
中文指南
设定交接边界
这项建议的流程做法只适用于自定义系统、相关业务记录、附件功能和交接版本都已经确定之后。目的，是约定如何演示并记录一次附件替换；交付物是一份附件版本验收工作表，而不是声称所有上传文件都可永久追溯的笼统结论。
先准备有日期的范围或版本编号、要审阅的记录类型，以及已经获准替换附件的角色。用稳定的测试记录编号标明业务记录。把问题写成可观察的语言：获准角色替换附件后，审阅者能否在已约定功能内区分当前文件与较早文件？
不要把本次审阅混同于归档搜索、可携带导出、备份恢复、并发字段编辑、权限政策、一般 UAT，或新增画面和控制项的请求。一个有价值的问题可以揭示缺口，但不会自动加入本次版本；应记录缺口，并按既定范围决策流程处理。
- 仅用合成文件
- 写明交接版本
- 关联一个业务记录
- 确认替换角色
测试前约定证据
准备两份无害的合成文件，并给它们相同的显示文件名，例如 service-note.pdf，但让内容明显不同。在每份文件内放入清楚的版本标记，例如“合成版本 A”和“合成版本 B”。相同名称可测试审阅者是否只依赖文件名，而没有核实文件本身的识别证据。
在上传前，约定工作表要记录的项目：原始上传参考、拟替换参考、显示文件名、关联记录编号、操作角色、可见的当前版本结果、较早版本结果（如可见）、取回步骤、审阅者和决定。版本参考可以是系统显示的编号、可见修订标签，或其他已约定的可观察区别；不要编造产品没有显示的技术编号。
GOV.UK 的用户故事指导支持以可观察的验收条件确认用户需要是否已实现。本工作表只是建议做法：把这一原则用于有限的交接审阅，不会规定产品设计。
- 准备不同内容
- 统一显示名称
- 记录版本参考
- 约定观察结果
执行受控替换
使用隔离的非生产环境和已约定的授权测试账户。先把合成原始文件上传到指定业务记录，记录显示文件名、版本参考或其他区别证据、记录关联和可见上传状态。确认工作表写的是实际观察，而不是团队对底层储存方式的猜测。
接着由已约定的替换角色提交同名的拟替换文件。不要为了完成测试而改权限、调整保留设置，或使用客户、员工、付款或真实营运文件。目标是可重复展示现有范围，不是模拟所有可能的文件事件。
通过既定的正常取回路径再次打开记录，辨认哪个附件被显示为当前文件。若产品在约定范围内显示较早版本，也按该路径打开或取回它，并比较可见区别证据。准确记录动作和结果；若产品只显示当前附件，就如实记录，不能推断较早版本存在于其他地方。
- 使用测试环境
- 先上传原始文件
- 按约定角色替换
- 按正常路径取回
核对内容而非名称
相同文件名不能证明内容、身份或替换历史相同。审阅者应打开当前文件，核对其中的合成版本标记；如已约定范围内可见较早版本，也应打开并核对其不同标记。工作表应写明实际读到或看到的内容，不应只写列表中有两个文件。
还要确认显示为当前的附件仍关联到正确的合成业务记录。这样可避免把技术上不同、却挂在错误工作、客户、任务或其他记录上的文件误判为通过。记录稳定业务编号和审阅者使用的取回路径。
不要把无法区分的结果变成关于不可更改、删除、保留或隐藏日志的结论。测试只能支持已约定环境中的观察结果。若无法预览文件，可记录另一种已约定且安全的方式来观察内嵌标记；否则把内容比对标为未完成，并说明原因。
- 打开当前文件
- 读取内嵌标记
- 核对关联记录
- 说明未观察事实
诚实处理例外
可采用三个简单结果。通过，表示已观察到约定的当前版本、记录关联和必需证据；带限制通过，表示已观察到当前版本和关联，但系统在约定范围内没有保留或显示较早版本，必须清楚写出限制；待决定，表示某项约定观察无法完成、证据冲突，或角色无法执行范围内动作。
较早版本不可用不一定就是缺陷。先对照有日期的已定范围：若从未约定保留历史版本，应记录该工作表不能证明此项。业务负责人或获授权的范围决策者随后可决定这个限制能否接受交接、是否需要澄清，或是否应成为独立的未来请求。
若替换动作可见，但当前文件无法与合成内嵌标记对应，不应只因文件名正确就通过。保留工作表，写下未通过检查，指定决策负责人；除非另有批准动作授权，否则不要在审阅过程中修改系统。
- 选择验收结果
- 清楚记录限制
- 指定决策负责人
- 避免扩大范围
虚构工作表示例
虚构例子：在记录 JOB-DEMO-17 上，已约定的协调员角色上传一份显示名称为 inspection.pdf 的合成文件，首页写着“合成版本 A”。工作表记录原始参考 UP-041、显示名称、记录关联和测试环境。协调员随后以另一份同样显示为 inspection.pdf、首页写着“合成版本 B”的文件替换它，可见参考为 UP-042。
审阅者通过普通记录视图重新打开 JOB-DEMO-17。当前附件打开后显示“合成版本 B”。一个历史区域也显示 UP-041，打开后显示“合成版本 A”。审阅者记录两次取回动作、观察到的参考和验收决定；决定只覆盖该记录、角色、环境与演示路径。这是虚构测试证据，不是关于客户或所有附件的证据。
如果没有出现历史区域，工作表可改为记录：已观察到当前附件 UP-042 与“合成版本 B”；这个已约定审阅路径未显示较早版本；没有演示历史保留。那是诚实的限制，不是声称隐藏恢复能力或规定保留期限的理由。
- 标明例子虚构
- 使用稳定测试编号
- 比较内嵌版本
- 限定决定范围
完成复用工作表
交接前，整理一份可读的验收工作表。内容包括有日期的范围或版本、环境、测试日期、合成记录编号、替换角色、原始与拟替换证据、显示文件名、当前版本观察、较早版本观察或限制、取回步骤、审阅者、决策负责人、结果和待办事项。证据位置应让交接记录的审阅者能够理解。
与有权接受这个有限结果的人一起审阅工作表。确认每项必需观察都已写明、未完成检查已清楚标记，并确认没有把新请求误当成已约定要求。一份简明的工作表比“附件历史可用”这种模糊说法更可靠。
当工作表已有记录决定，且每项限制都有明确下一步时，本指南即告结束。它不授权上传真实资料、修改权限、规定保留期、认证备份，或操作生产版本。除已记录的特定观察外，不承诺结果。
- 完成所有工作表字段
- 写明验收授权人
- 列出待办事项
- 保持决定有限
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles