Read the rejected-row file before calling an import complete

MAJLS LABS

An import is not ready to hand over because its progress bar stopped. Account for every submitted row, preserve the exact rejection reasons and give unresolved work to a named person. A technically accepted row still needs business checks. A missing outcome is unknown, not a license to submit it again.

This worksheet is for an administrator reviewing an import outcome. It answers “where did every original row end up?” It does not decide whether an uncertain write may be retried or authorize any correction.

Read the result at the right level

Tools expose different outcome units. HubSpot distinguishes a whole row not imported from one property value not imported while other columns in the row can import.^[1] It also notes that new or updated record counts need not match input-row counts.^[1] Do not force those numbers into a one-row/one-new-record equation.

Microsoft’s model-driven-app guidance separates successful, failed and partially imported records after an import completes.^[2] It describes exporting failed rows with Export Error Rows.^[2] HubSpot’s error file identifies an error code, object type, reason and record property values.^[1] Read that detail, not only the job summary.

These are source-specific examples of why result review matters, not a claim that all importers share a schema. Before using the worksheet, establish whether your tool reports rows, values, objects or several outcomes per row. Partial application must remain separately visible; it cannot be relabeled wholly rejected or fully accepted.

Worked example: a five-row equipment catalogue

Synthetic rehearsal. The people, equipment, submission, receipts and destination snapshot below are fictional fixtures. No import, repair or stock adjustment was performed. These are mock outcomes for a deliberately simple teaching importer, not HubSpot or Microsoft output. The reason codes are local fixture labels, not vendor error codes.

The fictional importer treats each row atomically, requires a department and allows only Studio, Workshop, Office or Lab. Its mock result contract carries the original stable row reference. I-v1 is the complete frozen input; header rows are not data rows. All values shown are literal strings; "" means empty. References are independent of item codes and remain fixed after sorting.

Submission fixture SYN-IMPORT-01 binds these five rows. Its preserved result set contains two accepted entries in OK-v1, two rejected entries in ERR-v1 and a job-level note NOTE-v1:1: "Result capture interrupted before all row outcomes were obtained." That note does not identify the missing row’s outcome.

Here is the complete row-accounting register. Receipt order intentionally differs from input order: match stable references, not screen positions.

The accepted clamp demonstrates why “the tool accepted it” is not business signoff. Its technical classification remains accepted while its description discrepancy remains held. Do not move it to rejected merely to make the queue look consistent.

Framework: counts plus set equality

For this atomic-row fixture, let S be original submission references, A accepted references, R rejected references and U references without a trustworthy outcome. Calculate U = S minus (A union R) only after checking for duplicates, overlaps and out-of-scope references.

The fixture gives 5 submitted = 2 accepted + 2 rejected + 1 unknown. The observed result references cover four of five rows. The sets are disjoint and their union equals the source set. The outcome review is not closed because one outcome remains unknown and three other rows have unresolved correction or business-review work.

Counts alone are insufficient: a duplicated receipt and an omitted source row could leave the total unchanged. If one row appears as both accepted and rejected, stop classification and reconcile the conflict. For a tool with partial application, add an explicit partial category and field-level evidence; do not reuse this fixture’s three buckets unchanged.

Human-owned correction queue

Lina Haddad, fictional preparer, preserves evidence and proposes corrections. Nabil Saleh, fictional catalogue owner, decides business meaning and whether a correction proposal is appropriate. Consequential approval remains with named human owner Nabil Saleh, never the assistant. Neither fictional name conveys actual MAJLS authority.

• Q-02, row 02: Lina obtains a department-bearing source record. Nabil approves or rejects the exact proposed department. Pending; original blank and rejection reason retained.
• Q-03, row 03: Lina compares the source, result mapping and destination snapshot. Nabil decides which description is correct and opens any separately authorized correction. Pending; no overwrite or assumed successful fix.
• Q-04, row 04: Lina proposes "Offcie" → "Office" only with supporting source evidence. Nabil decides the intended department. Pending; an obvious-looking typo is not identity evidence.
• Q-05, row 05: Lina obtains read-only evidence for SYN-IMPORT-01 and the original item reference. Nabil reviews the reconciled outcome. Pending; absence from a downloaded reject file does not establish success or failure.

Handoff checklist

• [ ] Freeze the original submission, mapping version, job reference and every result file; retain exact reason strings.
• [ ] Link each result to its original row using a verified key or the tool’s documented mapping contract. Stop on ambiguous links.
• [ ] Check reference-set coverage, duplicates, conflicts and partial effects before interpreting totals.
• [ ] Separate technical acceptance from business correctness; keep both statuses in the packet.
• [ ] Give each correction or unknown outcome a named owner and evidence task. No replay, rollback or repair follows from this worksheet.

Hand over the register and open queue together. “All rows accounted for” is an evidence claim. “All business data correct” is a different decision—and neither is established by a finished progress bar.

Discuss the process with MAJLS ↗