A CSV import is a business change disguised as a file upload. It may create customers, overwrite prices or alter stock records in seconds. The useful safeguard is a reviewable explanation of what the import will do. Small businesses often inherit spreadsheets with inconsistent naming, date formats and identifiers, so an import should expect ambiguity and make the important decisions visible before applying them.
Define what each row means
Consider a Darwin distributor importing a supplier catalogue. One row might represent a product, a product variant or a supplier-specific pack size. Agree that meaning before mapping columns. Identify the stable key used to recognise an existing item; a product name is rarely a reliable substitute for an agreed code. Show how blank values are treated. A blank selling price could mean leave unchanged, clear the value or reject the row, and those choices have very different consequences. Make the selected rule visible in the preview.
Validate the file in context
Check more than whether a value looks like a number. A quantity may need a unit, a date may be ambiguous, and a code may refer to an inactive category. Report issues with row numbers, field names and plain-language explanations. Preserve the original file so staff can relate the error report to what they supplied. Separate blocking errors from warnings, and explain the consequence of proceeding with warnings. For a large file, summarise the issue types while still allowing the operator to inspect individual examples.
Agree the commitment boundary
Should the import apply only if every row is valid, or accept valid rows and return the rest for correction? Neither choice is universal. An all-or-nothing approach is easier to reason about for a linked price change; partial acceptance may suit independent contact updates. PostgreSQL documents transactions as a way to group changes that succeed or fail together. The application still needs to choose the right grouping and communicate it. Include a batch identifier so imported changes can be investigated later without guessing which upload produced them.
Prove the preview with a small file
Prepare ten fictional rows containing a new item, an update, a duplicate code, an invalid date and an intentional blank. Confirm that the preview describes the actual result. Before a live import, review:
- The matching key and treatment of duplicate rows.
- Counts of creations, updates, unchanged records and rejected rows.
- The handling of blank values and ambiguous Australian date formats.
- The recovery approach if the wrong file or mapping is selected.