This is a review workflow for the CSV import extension, not a claim that a conversation updates your base. If the extension is unavailable under your account's permissions or plan, confirm access with your administrator; do not assume that another import screen has identical merge controls.
Use a key that identifies a record
The original fictional base has two records:
contact_id,display_name,region
C101,Alex Lee,West
C102,Alex Lee,East
The incoming update file is:
contact_id,display_name,region
C101,Alex Lee,North
c102,Alex Lee,South
,Jamie Park,Central
The two Alex Lee records belong to different people. Their names cannot decide identity. The source owner says IDs are case-sensitive; C102 and c102 are therefore different keys unless that owner corrects the file.
Airtable's CSV import extension documentation, checked October 24, 2026, describes merging on a selected unique field. It specifies case-sensitive matching, ignores leading/trailing whitespace for matching, and says blank merge keys create records.
Predict the import before opening the final confirmation
With contact_id selected as the merge field, C101 matches an existing record. c102 does not match C102. The blank-key row also creates a new record under the documented behavior. For this file, the expected classification is one update and two new records, taking the table from two records to four if the import is accepted as supplied.
Those are authored expectations, not a completed import. Quarantine the blank-key row and ask its owner for an ID. Ask whether c102 is genuinely new or a mistaken spelling of C102. Do not uppercase all identifiers simply to produce a match.
Review an Airtable CSV import-extension merge plan. Do not import.
Existing rows and field types: [PASTE PERMITTED SAMPLE]
Incoming CSV with stable source row numbers: [PASTE]
Chosen merge field and identity/case policy: [ENTER]
Approved mapped fields and blank-value overwrite policy: [ENTER]
Classify each incoming row as update, new or unresolved using the
documented case-sensitive matching behavior. Flag blank and repeated
keys before import. Show target record, proposed changed fields and
expected record counts. Do not merge people by display name, invent
IDs, normalize case without approval or infer that blank means delete.
Return a held-row list and questions for the source owner. I will
inspect Airtable's native mapping and preview before any import.
The task context and requested output follow OpenAI's prompting guidance. Use only data your organization allows you to supply.
Resolve held rows, then reconcile the native preview
Suppose the owner confirms the second row should be C102 and leaves Jamie's row on hold. The corrected two-row file should update C101 and C102 without adding records. Check that prediction against the extension's actual preview in a test copy.
Map contact_id to the intended ID field and region to region. Review the extension's blank-value setting against the approved overwrite rule; skipping a blank field is different from deciding the identity of a blank-key row. Check the individual record previews as well as aggregate counts.
After an authorized test import, inspect both IDs and regions and confirm there are still two records. For source-value normalization, the data-cleaning guide covers preserving raw values and approving transformations. Keep that preparation separate from the decision to create or update records in the maintained base.