← All articles

AI app guides

Design CSV imports with a preview before records change

Map columns, expose rejected rows and define what happens when the same file is imported twice.

Zocri · 2 min read · Sources checked

Treat the file as structured input

RFC 4180 documents CSV quoting for fields that contain commas, line breaks or double quotes. That matters when a customer name or address contains punctuation. An import should use an appropriate parser and display what it understood, rather than assuming every comma separates a field. The owner needs a preview before the file changes the app's records.

Start with a small representative export from the actual source system. Include headers, a quoted address and an empty optional value. Decide which app fields are required and how columns map to them. Do not guess that a column called status uses the same meanings as the destination app.

Validate rows with useful explanations

Show accepted and rejected rows separately, with a reason tied to the relevant field. An invalid date, an unknown category and a duplicate identifier are different problems. Let the user correct the file or mapping without losing the context needed to understand why the row was refused.

Define how identifiers and leading zeros are handled. A customer reference can look numeric while functioning as text. Similarly, ambiguous dates should be interpreted under an explicit rule. Preview the resulting values so the owner can catch a mistaken conversion before it spreads across many records.

Choose the repeat-import policy

Decide whether importing the same identifier updates an existing record, skips it or requires review. Do not allow a second upload to create duplicate customers unless that is the intended behavior. Show the proposed counts for new, changed, skipped and rejected records before confirmation.

For partial failures, state whether valid rows are applied or the entire import is refused. Either policy can work when clearly explained. Keep an import reference and enough result detail to reconcile what changed, and define a supported correction or reversal process before using a large file.

Reconcile the result after confirmation

Test the import with a handful of records, then inspect them through the normal app interface. Compare counts and important fields with the preview. Import the same file again and verify the chosen duplicate policy, then try one changed row and one malformed row.

Keep the original file and result report according to the organization's handling rules. Limit access if the file contains personal information. A useful import workflow gives the owner a chance to inspect interpretation, understand refusals and explain the final changes, rather than turning a successful upload into an assumption that every record is correct.

Put it into practice.

Open Zocri →