When a CSV import says complete but the data is wrong: lessons from Airtable and Notion
Airtable and Notion document different import behaviors. Use the differences to design clearer mapping, completion messages and recovery after a first upload.
In this article
An import can finish and still leave a new user with the wrong data. Airtable’s CSV import extension documentation explicitly warns that a value a field cannot accept may become an empty cell while the record is still created or updated. The import summary does not list those skipped values. For onboarding, the useful finish line is therefore a result the person can inspect and trust, not the disappearance of an upload indicator.
Airtable and Notion expose another important distinction: “merge” does not mean the same thing in every product. The differences suggest a better way to explain the first import, from mapping through completion and repair.
Explain what the operation will do to existing work
The comparison below concerns Airtable’s CSV import extension and Notion’s CSV importer, including its Merge with CSV option. These are the products’ published descriptions, checked October 15, 2026; no import was performed for this comparison.
| Question before importing | Airtable CSV import extension | Notion CSV import |
|---|---|---|
| Can the operation update existing records? | Yes, when merge is enabled and rows match the selected field. | Imports and CSV merges add rows; they do not update existing rows. |
| What does mapping connect? | CSV columns to destination fields. | CSV columns to database properties. |
| What happens to problematic values? | Unacceptable values can leave cells empty while records are created or updated. | Guidance recommends text properties for some troublesome numeric or Select values. |
| What should a user check before repeating it? | The merge field, mappings and intended updates. | Whether repeating the import will add unwanted duplicate rows. |
Sources: Airtable extension and Notion’s CSV section.
That comparison changes the recovery advice. A generic “Fix your file and try again” cannot tell the user whether the next attempt replaces the first result or creates another one. The importer should name the operation in the user’s terms before it runs: add new items, update matching items, or a combination that is explicitly described.
Put that explanation beside the decision. A person choosing a destination table needs to understand what will happen to the records already there. They should not have to interpret the word “merge” from experience with another application.
Preview the values most likely to expose a mapping mistake
A tidy first row is a weak demonstration of whether a file will work. Consider this invented contact file, shown here as a design exercise rather than a test of either product:
| Record | Incoming value | Question the preview should help resolve |
|---|---|---|
| A | A normal name and address | Does the basic mapping look right? |
| B | An empty company field | Will an existing company value be kept, cleared or left alone? |
| C | A date written as text | Can the destination understand it? |
| D | A category absent from the destination | Will it be created, rejected or omitted? |
| E | An identifier already in the destination | Will this create a duplicate or update the intended item? |
| F | The same identifier appearing again | Which record will the user expect to survive? |
The point is not to show every row before import. It is to make the consequences of the chosen rules visible. A preview can surface representative exceptions and explain the decision required for each one. If the product cannot identify exceptions in advance, say what it has checked and provide a concrete review step afterward.
Keep the original value visible beside any transformed value. If a date is being interpreted in an unexpected way, a user needs both versions to recognize the mistake. Showing only the destination’s interpretation can make a wrong result look authoritative.
Separate the receipt from the result
Design the completion view around three different questions: was the file received, what changes were applied, and what still needs attention? Those answers can appear together, but they should remain distinguishable.
For the invented importer, a useful completion message might say: “Your contacts were added. Review the rows marked ‘Needs attention’ before sending messages.” The action should open that exact review, with the source row and destination item connected. A toast that vanishes after a few seconds leaves the user to rediscover the problem later.
A completion view also needs a durable destination. Name the table, workspace or project where the imported material now lives. Let the person reopen it from the import record. For a first-time user, locating the result is part of the task; the location that seems obvious to the team may still be unfamiliar to them.
Make retry a deliberate operation
Notion’s documentation makes the risk concrete: CSV imports add rows rather than updating existing ones. A second attempt is therefore not a neutral way to repair the first. The product’s CSV guidance also notes that a new import cannot create formulas or rollups. A recreated spreadsheet appearance does not necessarily carry over its underlying behavior.
For a product you are designing, make the retry path state what will happen to prior work. If it appends another batch, name that. If it updates matching items, expose the matching rule. If recovery requires deleting the first batch, give the user a way to identify that batch and understand any consequences before proceeding.
Airtable recommends taking a snapshot before import and describes using it to recover from an incorrect merge. That is a different recovery mechanism from correcting individual cells. The appropriate choice depends on how much valid work would be undone along with the error.
Test the first useful action after import
A useful onboarding test continues beyond upload. Ask a new user to find a particular imported item, inspect a value that could have changed and complete the next intended task. A contact importer might lead into selecting a segment; a project importer might lead into assigning a task. Use an example where correctness can be recognized without specialist knowledge.
Observe whether the person can explain what changed and repair a known mistake. Record successful import separately from successful use of the imported material. The guide to resuming setup covers the return path; the import-specific addition is preserving enough context to know which attempt, file and operation created the current state.
If a user can reach the result but cannot tell whether it is right, the onboarding work is still unfinished.
