DEV Community: 两只喵的日常

How to use AI to check a CSV file before importing it into a CRM

两只喵的日常 — Fri, 19 Jun 2026 16:29:38 +0000

Importing a CSV into a CRM is one of those tasks that looks simple until it quietly breaks routing, attribution, lifecycle reporting, or duplicate handling.

AI can help, but the useful job is not "clean this CSV." The useful job is asking AI to create a review process before anything gets uploaded.

The real question

The question I would ask is:

How do I use AI to check this CSV before importing it into a CRM?

That is different from asking AI to rewrite the file. For CRM imports, the priority is preserving the fields that make the system work.

Fields to check first

Before asking AI to suggest cleanup rules, identify the fields that should not be changed casually:

Record ID or external ID
Email address
Owner
Lifecycle stage
Lead source
Company or account name
Created date or original source date
Required CRM fields
Any field used for routing, attribution, or reporting

If one of these fields is wrong, a technically successful import can still create bad business data.

A better AI prompt

Use a prompt like this:

I am preparing a CSV for CRM import.

Review the headers and sample rows below.

Return:
1. Fields that are safe to normalize.
2. Fields that need manual review.
3. Required CRM fields that are missing or incomplete.
4. Duplicate risks.
5. Owner, lifecycle, and lead source values that do not match the approved list.
6. A pre-import QA checklist.
7. Rows that should not be imported until reviewed.

Do not rewrite record IDs, email addresses, owner fields, lifecycle stages, or attribution fields without flagging the change.

Then paste the headers, a sample of rows, and your approved CRM field values.

What AI should return

A useful answer should give you a review table, not just a cleaned file.

For example:

Area	What to check	Why it matters
Owner	Missing, inactive, or misspelled owners	Prevents bad routing
Lifecycle stage	Values outside the approved list	Protects pipeline reporting
Lead source	Duplicated labels like PPC, paid search, Google Ads	Prevents attribution drift
Email	Missing or duplicated email addresses	Prevents duplicate contacts
IDs	Blank or changed CRM IDs	Prevents unsafe overwrites

The small-batch test

Before importing the full CSV, test a small batch.

Check:

Row count before and after import
Required field errors
Duplicate behavior
Owner assignment
Lifecycle stage mapping
Lead source normalization
Whether existing CRM fields were overwritten

Keep the original CSV and a rollback file.

A checklist version

I keep a practical version of this workflow here:

Sales ops CSV import QA checklist

The core idea is simple: use AI to make the import safer, not faster at the expense of review.

Final rule

If the CSV controls routing, revenue reporting, attribution, or customer ownership, AI should help you create a QA process. It should not be treated as an automatic cleanup engine.

A CSV import QA checklist for sales ops teams

两只喵的日常 — Thu, 18 Jun 2026 06:23:54 +0000

CSV imports are easy to underestimate.

The file opens in a spreadsheet, the rows look readable, and the cleanup seems small. Then the CRM import creates bad owner assignments, duplicate contacts, broken source reporting, or lifecycle values that do not match the dashboard.

Here is the QA checklist I would use before uploading a cleaned sales ops CSV.

1. Preserve IDs and rollback fields

Before cleanup, keep the raw file.

Do not overwrite:

CRM record IDs
email addresses
owner identifiers
account IDs
source record IDs
created dates

If the import fails, these fields are usually needed for rollback or deduplication.

2. Validate required fields

Before upload, check whether each row has the fields the destination system expects.

Common required fields:

email
company
owner
lifecycle stage
lead source
record ID
account ID

Missing required fields should be flagged, not guessed.

3. Normalize source labels

Source labels often drift over time:

PPC
Paid Search
paid search
Google Ads
Adwords

If these values enter the CRM as separate labels, reports become harder to trust.

Create a mapping table:

raw_value | approved_value | rule | review_needed

4. Check owners before upload

Owner fields affect routing and visibility.

Look for:

inactive owners
old rep names
initials instead of approved user names
team inboxes
blank owners

Rows with uncertain owners should go into review.

5. Separate exact duplicates from possible duplicates

Do not deduplicate only by name.

Better signals:

email
CRM ID
account ID
company domain

Name-only matches should usually be possible duplicates, not automatic merges.

6. Test a small batch

Before the full upload, test a small file with:

one normal row
one duplicate candidate
one missing owner
one unusual source label
one lifecycle edge case

This catches validation problems without damaging the full dataset.

I keep a more complete checklist here:

https://trendstackai.com/resources/sales-ops-csv-import-qa-checklist.html?utm_source=manual&utm_medium=devto&utm_campaign=third_round_links&utm_content=sales-ops-csv-import-qa

The goal is not to make the CSV perfect. The goal is to make the import safe enough that the team can understand what changed and roll back if needed.

Why CSV imports fail after cleanup: delimiter, encoding, and mapping checks

两只喵的日常 — Thu, 18 Jun 2026 05:35:26 +0000

CSV import failures are often blamed on the destination tool, but many failures start earlier: the file was cleaned in a spreadsheet, saved with different settings, or mapped into fields that no longer match the target system.

If a CSV opens locally, that does not mean it is import-safe. Spreadsheet apps are forgiving. Importers are usually stricter.

Here is the checklist I use before rerunning a failed CSV upload.

1. Confirm the delimiter

The most basic CSV failure is also the easiest to miss.

A file may be separated by:

commas
semicolons
tabs
pipes

If the importer expects commas but the file uses semicolons, the upload may collapse every row into one field. If text fields contain commas without proper quoting, the importer may shift values into the wrong columns.

Before changing field mappings, check whether the row structure is being parsed correctly.

2. Check encoding before editing more rows

Encoding issues usually show up as broken names, symbols, or special characters.

Common signs:

accented characters look corrupted
currency symbols change
names from non-English markets break
smart quotes become unreadable
imported text does not match the source export

If the data includes names, addresses, product titles, or international text, confirm the export is UTF-8 before rerunning the import.

3. Preserve IDs as text

IDs are not normal numbers.

These values should often stay as text:

Value	Risk
000123	leading zeros disappear
2026-001	parsed as a date
C-1042	treated as a category
1E10	interpreted as scientific notation

Once IDs change, it becomes harder to reconcile imported records with the original source.

4. Recheck column mapping after cleanup

Cleanup can change the meaning of a column.

For example:

a combined contact field may become separate name and email fields
a status column may be normalized into a smaller approved list
a company name may need to match a linked record table
a date field may be converted into a new format

After cleanup, do not reuse the old mapping blindly. Build a small mapping table:

Source column	Target field	Field type	Cleanup rule
Contact ID	Source ID	Text	Preserve exactly
Company	Company	Linked record	Match primary field
Status	Status	Single select	Normalize values
Created At	Created date	Date	Convert to ISO format

5. Test representative rows, not random rows

The first five rows are not always a good test.

Pick rows that include:

one normal record
one record with a blank optional field
one record with a linked record value
one row with date or currency values
one row with commas, quotes, or line breaks in text

This catches parsing and mapping issues before they affect the full upload.

6. Keep a post-import review view

After the test import, review:

blank required fields
duplicate source IDs
unexpected select values
invalid dates
unmatched linked records
row counts before and after import

This step matters because some failures are not visible in the upload preview.

I keep a more detailed guide here: CSV encoding and delimiter fix guide

The safest CSV cleanup process is not just about making the file look clean. It is about preserving the values that the destination system depends on.

How to map CSV columns before importing into Airtable linked records

两只喵的日常 — Wed, 17 Jun 2026 19:15:39 +0000

CSV imports into Airtable often fail for reasons that are not obvious from the import screen. The file may look clean, the headers may be readable, and the preview may even show the right rows. The real problem is usually the mapping between source columns, Airtable field types, and linked record behavior.

This is the workflow I use before importing operational data into Airtable, especially when the base has linked records, select fields, IDs, or messy exports from another system.

Start with a mapping table

Before touching the importer, map the CSV in a small table:

CSV column	Airtable field	Field type	Required?	Cleanup rule
Contact ID	Source ID	Single line text	Yes	Preserve exactly
Company	Company	Linked record	Yes	Match primary field
Status	Status	Single select	No	Normalize labels
Notes	Notes	Long text	No	Keep raw text
Created At	Created date	Date	No	Convert to one date format

This table makes the import decision explicit. It also helps you avoid changing the Airtable schema while you are already inside the upload flow.

Separate identifiers from names

A common mistake is treating every readable value as a display label. In practice, imports usually contain two different kinds of columns:

stable identifiers, such as customer IDs, ticket IDs, order IDs, or source system IDs
human-readable labels, such as company names, contact names, status labels, or category names

Preserve stable IDs exactly. Do not trim leading zeros, convert them to numbers, or merge them into display fields. If something goes wrong later, those IDs are what let you compare the imported Airtable records against the original export.

Be careful with linked records

Linked records deserve special attention. If the CSV value does not match the linked table's primary field, the import can look correct but still fail to create the relationship you expected.

For example, if your CSV has a Company column with values like "Acme Inc" but the linked Companies table uses "Acme" as the primary field, Airtable may not match the existing company record. You can end up with blank links, duplicate linked records, or records that look valid but are not connected correctly.

Before importing linked records, check:

whether the linked table already contains the target records
whether the CSV value exactly matches the linked table primary field
whether you want Airtable to create new linked records automatically
whether duplicate names exist in the linked table
whether the import should use a text staging field first

For risky imports, I usually import into a temporary text field first, review the values, then convert or map them into linked records after the mismatch cases are visible.

Normalize select fields before import

Single select and multi-select fields can create messy option lists if the CSV contains small variations.

These values may all represent the same status:

Active
active
ACTIVE
Active customer
Current

Decide the final Airtable labels before import. Otherwise, you may create duplicate select options and have to clean the base after the data is already live.

Test with five representative rows

Do not test with the first five rows unless they represent the full data shape. Pick rows that include:

one normal record
one record with a linked record value
one record with missing optional fields
one record with date or number fields
one record with edge-case text, such as commas, line breaks, or unusual characters

This small test catches most mapping errors before the full import creates hundreds or thousands of records.

Create a post-import review view

After import, create a review view that filters for likely problems:

blank required fields
unmatched linked records
duplicate source IDs
unexpected select values
invalid dates
records created during the test import

This view is useful because import errors are not always visible in the upload screen. Some issues only become obvious after the records exist in the base.

Practical checklist

A safe CSV to Airtable import usually looks like this:

Preserve the raw CSV.
Identify IDs, names, dates, categories, notes, and linked-record candidates.
Build a mapping table before import.
Decide which fields should be linked records.
Normalize select values before upload.
Test five representative rows.
Review blanks, invalid values, duplicates, and unmatched linked records.
Keep the source ID field for rollback and reconciliation.

I keep a more detailed CSV to Airtable field mapping checklist here: CSV to Airtable field mapping checklist