B2B app CSV imports: preview the changes before saving

A CSV import can make a new business app useful quickly, but a successful upload is not the same as a successful migration. Before building an import button, decide what users need to understand before records change and how they will recover from a mistaken file. A first release can support one narrow import well instead of accepting every spreadsheet format.

1. 01

   Consider a small service company importing its customer directory. Its spreadsheet has a customer number, company name and contact email. Some rows are missing customer numbers, and two rows refer to the same company with different email addresses. The product needs an explicit matching rule. An email address alone may be a poor identifier when several people share an inbox or an existing contact changes their address.

2. 02

   Start with a sample template and a mapping preview. Show which input column will populate each supported field, which fields are required and which columns will be ignored. Preserve customer numbers as text if leading zeros are meaningful. Use a few representative rows to make the mapping understandable, then validate the entire file before offering to apply it. A clean preview of the first five rows says nothing about an invalid row near the end.

3. 03

   Separate three outcomes in the review: records to create, records to update and rows that need correction. For an update, show the existing value beside the proposed replacement. Decide whether a blank cell means leave unchanged or clear the field; either interpretation can be reasonable, but silently mixing them makes recovery difficult. If the file repeats a customer number, ask for correction or apply a documented rule rather than allowing row order to decide accidentally.

4. 04

   Choose the failure model deliberately. Rejecting the whole file when any row is invalid is easier to explain for a small initial directory. Accepting valid rows while rejecting others can help with larger files, but requires a clear result report and a retry process that does not duplicate the successful rows. The MVP tradeoff is between flexibility and the support burden of partially completed work. Match the choice to the operator's actual workflow.

5. 05

   Give every import a result record: when it ran, who initiated it, counts of created and updated records, and a file-specific row reference for each error. Keep detailed customer values inside the authorized application, not general analytics. An import history also needs access rules; a useful troubleshooting screen should not expose a directory to someone who cannot otherwise view it.

6. 06

   Plan recovery before promising an undo button. Restoring old values can overwrite legitimate edits made after the import. For a first release, an administrator-assisted correction process may be more honest than unrestricted rollback. Record enough information to identify affected records, and check for subsequent changes before restoring anything. Explain that process in the completion screen so a user knows how to report a mistake.

7. 07

   Test an empty file, a file with missing columns, repeated identifiers, blank updates and a retry after an interrupted response. Include identifiers with leading zeros and names containing punctuation. Check that the final counts match the records actually stored and that a retry follows the chosen matching rule. In a pilot, measure successful first attempts, correction cycles and support requests about unclear outcomes. Those observations reveal whether the import is helping onboarding more clearly than counting upload-button clicks.