Set a narrow review boundary
Use this suggested workflow practice only after the custom system, the relevant record type, and the import format are already scoped. The deliverable is one import exception acceptance worksheet for one bounded synthetic batch in an isolated test environment. It answers a practical question: did the product show the agreed behaviour for each planned valid, deliberately invalid, and unresolved row in this batch?
Do not turn the worksheet into a production-import procedure or a cutover decision. It does not authorise live data loading, certify backups, reconcile report totals, define retry behaviour, or promise transactional protection. It also does not require a particular implementation method. The product should demonstrate its agreed behaviour; the reviewers record what they can observe.
Start with a dated scope or release reference, environment identifier, import format or template version, and named business reviewer. State the record group and the exact batch boundary. If the source file, column meaning, or expected rule is unknown, mark the review unresolved rather than guessing. Keep real personal, customer, staff, payment, or operational data out of the exercise.
- Dated scope reference
- Isolated test environment
- Synthetic batch boundary
- Named review authority
Prepare one traceable synthetic file
Create one small fictional file whose identity can later be recognised. Give it a file name, version, preparation date, preparer, format, and, where useful, a file checksum or stored copy reference. Use invented identifiers and plainly fictional values. Do not reuse a spreadsheet that might contain hidden real data, copied contacts, or live operational notes.
Assign every row a stable row reference before the test. A visible test-row ID is often safer than relying only on a changing spreadsheet line number. Record the intended classification for each row: expected valid, deliberately invalid, or unresolved by design. For deliberately invalid rows, write the specific condition being exercised, such as a missing required value, an unsupported value, or a duplicate reference only where that rule is already agreed.
Write expected results in observable terms. For a valid row, specify the expected accepted outcome and evidence location. For an invalid row, specify the expected rejection signal, actionable reason, and evidence that no record or field effect was silently applied. For an unresolved row, state the question and decision owner; do not label it valid merely to finish the test.
- Source file identity
- Stable row reference
- Expected classification
- Observable expected result
Run the bounded import and capture evidence
Before running the file, record the release or build reference, the authorised test account or role, the time context, and the person performing the action. Keep the run limited to the agreed synthetic file. If the environment contains prior test records, note the relevant starting condition so a reviewer can distinguish this run from earlier activity.
Run the import once through the agreed product path. Capture the visible result for the batch and for each exception: screen result, downloadable error output, test log reference, or another retained artefact that the team can access. Evidence should identify the batch and row sufficiently to support a later review without exposing real data.
For rejected rows, look for more than an error message. Use the available product evidence to check whether the row was not silently applied. Depending on the agreed design, that may mean no corresponding synthetic record can be found, no stated field change appears, or a visible outcome marks the row as rejected. Record only what was actually checked. Do not infer that every technical side effect is absent or that future files will behave identically.
- Release reference saved
- Import performer named
- Row outcome captured
- Non-application evidence
Classify results without hiding uncertainty
Use three outcomes consistently. Accepted means the observed result matches the agreed valid-row expectation. Rejected means the product visibly declined the planned invalid row, supplied a useful reason or identifiable error reference, and the worksheet contains evidence of the agreed non-application check. Unresolved means the result, reason, evidence, or intended rule cannot yet be confirmed.
An actionable reason helps the file preparer correct the next version. “Failed” alone is too weak. A useful entry identifies the row reference, affected field or rule where visible, observed message or error reference, and the practical correction question. If the message is vague, record it faithfully and assign the question to the person who can clarify the intended format or system behaviour.
Do not force a rejected outcome where an error is visible but non-application cannot be checked. Record it as unresolved with a named retest or investigation decision. Likewise, do not declare an accepted row correct only because it appears in a list; compare the agreed fields or state that the field-level check was not performed. Observable criteria help keep the acceptance decision connected to evidence rather than a broad statement that the import works.
- Accepted outcome checked
- Rejected reason recorded
- Unresolved gap stated
- Decision owner named
Decide correction and retest handling
When a rejected row can be corrected, create a corrected-file reference rather than overwriting the original test file without trace. Record which source version was changed, which row references changed, what was changed, who prepared it, and why the correction addresses the recorded reason. Preserve the original file reference and its observed outcome as part of the worksheet history.
Make a separate named retest decision for every corrected or unresolved item: retest approved, no retest needed because the item is out of scope, or hold pending a scope or product decision. A retest decision should name the owner and the condition for closing it. It is not an instruction to build automatic retry, deduplication, idempotency, or a production process.
If a requested correction reveals an unagreed field, format, mapping, or business rule, stop classifying it as a simple data correction. Log it as a scope question or defect decision under the team’s existing process. The import worksheet can link to that decision, but should not quietly expand the release.
- Original file preserved
- Corrected file referenced
- Retest decision recorded
- Scope question separated
Work through a fictional batch
Fictional example: the isolated test file “Harbour-Demo-Intake-v1.csv” contains four invented rows for an already-scoped service-request record. Row DEMO-01 has all agreed values and is expected to be accepted. Row DEMO-02 deliberately leaves the agreed required request reference empty and is expected to be rejected. Row DEMO-03 uses an invented category whose permitted values are unclear in the agreed scope, so it is marked unresolved before the run. Row DEMO-04 is valid except for a deliberately malformed date under an agreed date format.
After the run, the worksheet records DEMO-01 as accepted with a test-record reference. DEMO-02 and DEMO-04 show rejection messages tied to their row references; the reviewer also records that no matching synthetic records were found through the agreed test search. DEMO-03 produces a rejection, but its message does not explain whether the category is unsupported or the mapping is incomplete. It remains unresolved, assigned to the scope owner, not silently counted as a failed data entry.
The preparer creates “Harbour-Demo-Intake-v2.csv” for DEMO-02 and DEMO-04, preserving v1. The named reviewer approves a limited retest of those rows after correction. DEMO-03 is held until the scope decision identifies allowed categories. This worksheet supports a bounded evidence review only; it does not decide live handover or approve an operational import.
- Fictional data confirmed
- Batch outcomes listed
- Correction version linked
- Handover boundary retained
中文指南
先设定狭窄审阅边界
只在自定义系统、相关记录类型和导入格式已经确定后，采用这项建议的工作方法。交付物是一份针对单个合成测试批次的导入异常验收工作表，测试必须在隔离环境进行。它回答的是一个具体问题：这个批次中预定有效、故意无效和尚未确定的每一行，产品是否展示了已约定的行为？
不要把这份工作表变成生产导入流程或上线切换决定。它不授权导入真实资料，不证明备份可用，不核对报表总数，也不规定重试方式或承诺事务保护。它同样不要求某种技术实现；产品应展示已约定的行为，审阅者只记录实际可观察到的结果。
先填写有日期的范围或版本参考、环境标识、导入格式或模板版本，以及指定的业务审阅人。说明记录组和批次边界。若来源文件、栏位含义或预期规则不清楚，应标为未解决，不能猜测。练习中不得使用真实个人、客户、员工、付款或运营资料。
- 已标日期范围
- 隔离测试环境
- 合成批次边界
- 指定审阅权限
准备可追溯合成文件
建立一个小型且完全虚构的文件，让日后审阅者能够识别它。记录文件名、版本、准备日期、准备人、格式，以及在适用时的校验值或保存位置。使用虚构编号和明显虚构的内容。不要重复使用可能藏有真实资料、复制联系人或真实运营备注的表格。
在测试前为每一行分配稳定行参考。可见的测试行编号通常比会变化的表格行号更可靠。记录每行预期分类：预期有效、故意无效或设计上未解决。对于故意无效行，写明正在测试的具体条件，例如缺少必填值、不支持的值，或仅在重复规则已约定时测试重复参考。
用可观察的语言写预期结果。有效行应说明预期接受结果和证据位置。无效行应说明预期拒绝信号、可处理原因，以及该行没有被悄悄应用的证据。未解决行应写明问题和决定负责人，不能为了完成测试而把它标为有效。
- 来源文件身份
- 稳定行参考号
- 预期结果分类
- 可观察预期结果
执行限定导入并保留证据
导入前，记录版本或构建参考、获授权的测试账户或角色、时间背景和执行人。运行范围只限已约定的合成文件。若环境已有旧测试记录，记下相关起始状态，让审阅者能区分本次运行和早前测试。
通过已约定的产品路径只运行一次导入。保留批次和每个异常的可见结果：页面结果、可下载错误输出、测试日志参考或团队可取得的其他凭据。证据应足以识别批次和行，但不应暴露真实资料。
对于被拒绝的行，不只查看错误讯息。利用产品可提供的证据检查该行没有被悄悄应用。按已约定的设计，这可能表示找不到相应合成记录、指定栏位没有变更，或可见结果把该行标记为拒绝。只记录实际检查的项目；不要推断所有技术副作用都不存在，也不要推断未来文件一定相同。
- 版本参考已保存
- 执行人员已命名
- 行结果已捕获
- 未应用证据保留
分类结果但不隐藏未知
持续使用三种结果。已接受表示观察结果符合有效行的约定预期。已拒绝表示产品明显拒绝预定无效行、提供有用原因或可识别错误参考，并且工作表保留了已约定的未应用检查证据。未解决表示结果、原因、证据或预期规则仍无法确认。
可处理原因应帮助文件准备人修正下一版本。只写“失败”并不足够。好的记录应包含行参考、可见的受影响栏位或规则、观察到的讯息或错误参考，以及实际的修正问题。若讯息含糊，应如实记录，并交给能澄清格式或系统行为的人。
若画面显示错误但无法检查未应用状态，不要强行列为已拒绝。应标为未解决，并写明调查或复测决定。同样，行出现在列表中不代表一定正确；应核对已约定栏位，或说明没有做栏位层面的检查。可观察验收条件让决定基于证据，而不是笼统地说导入正常。
- 接受结果核对
- 拒绝原因记录
- 未解缺口说明
- 决定负责人命名
决定修正与复测处理
当拒绝行可以修正时，应建立修正后文件参考，而不是无痕覆盖原测试文件。记录改变了哪个来源版本、哪些行参考改变、改变内容、准备人，以及该修正为何回应了已记录原因。原文件参考和观察结果应作为工作表历史的一部分保留。
每项已修正或未解决内容都要有独立的指定复测决定：批准复测、因超出范围而无需复测，或等待范围或产品决定。复测决定要写明负责人和结案条件。它不是要求建立自动重试、去重、幂等机制或生产流程。
若修正请求揭示了未约定的栏位、格式、映射或业务规则，就不应再当作简单资料修正。按团队既有流程记录为范围问题或缺陷决定。导入工作表可以链接该决定，但不能静默扩大当前版本范围。
- 原始文件保留
- 修正文件可追溯
- 复测决定已记录
- 范围问题分开处理
查看一个虚构批次例子
虚构例子：隔离测试文件“Harbour-Demo-Intake-v1.csv”包含四行已约定服务请求记录的虚构资料。DEMO-01 具备全部约定值，预期被接受。DEMO-02 故意遗漏已约定的必填请求参考，预期被拒绝。DEMO-03 使用范围中尚未说明允许值的虚构分类，因此运行前标为未解决。DEMO-04 其他资料有效，但故意使用不符合已约定格式的日期。
运行后，工作表把 DEMO-01 记录为已接受，并附测试记录参考。DEMO-02 与 DEMO-04 显示各自行参考对应的拒绝讯息；审阅者也记录透过已约定测试搜索找不到匹配合成记录。DEMO-03 被拒绝，但讯息没有说明是不支持该分类还是映射不完整，因此仍为未解决，并交给范围负责人，不能悄悄算作资料输入失败。
准备人建立“Harbour-Demo-Intake-v2.csv”以修正 DEMO-02 和 DEMO-04，并保留 v1。指定审阅者批准只针对修正行进行有限复测。DEMO-03 保留等待范围决定确认允许分类。这份工作表只支持有限证据审阅，不决定真实交接，也不批准运营导入。
- 确认完全虚构
- 批次结果列明
- 修正版本关联
- 交接边界保留
Sources and next step
Discuss your workflow scope with BossFlow · Compare system categories at SME Systems · All articles