CRM CSV import or browser updates: choose by the work you have
You have a prepared prospect file: names, emails, company domains and a few fields you want in the CRM. The next decision is about method. You can import the file, or you can open records one at a time and edit them. Choosing wrong causes trouble either way. A careless import can overwrite good data across hundreds of records. Hand-editing a clean, consistent file wastes an afternoon.
This guide helps you decide batch by batch. It uses HubSpot as the worked example because its matching and restore rules are publicly documented. Other CRMs behave differently, so check your own CRM’s deduplication rules before you rely on any of this.
If you still need to build and deduplicate the prospect table, start with Turn prospect research into a deduplicated CRM import. This article assumes that work is done.
The decision table
Score each batch against these five questions. If most answers land in the left column, import. If most land on the right, make reviewed edits. Mixed batches usually split cleanly into two files.
| Question | Favors CSV import | Favors reviewed browser edits |
|---|---|---|
| Existing IDs | Each row carries a reliable match key, such as a CRM record ID, email (contacts) or domain (companies) | Rows can only be matched by name, or several records could match |
| Field consistency | Same columns, same formats, same kind of change on every row | Each record needs a different field or a judgment call |
| Record volume | Many rows receive the same treatment | A handful of records, each slightly different |
| Exceptions | Few, and fixable in the file before import | The exceptions are the job: conflicts, missing context, partial matches |
| Preview and rollback | You can fix mapping errors before import and know how to restore afterwards | You need to see each record’s current value before anything is saved |
Native import is the better tool whenever the left column fits. It is built for repeatable, structured changes, and you should use it for them.
How HubSpot matches imported records
Before importing, know exactly which column the CRM will use to decide “update” versus “create.” In HubSpot (deduplication documentation):
- Contacts deduplicate by email address. An import row with an existing contact’s email updates that contact instead of creating a duplicate.
- Companies deduplicate by primary domain name. On import, primary and secondary domain values are both used, unless you select a custom unique property instead.
- Record ID can be used to match contacts, companies, deals, tickets, products and custom objects on import.
- Custom unique-value properties (up to ten per object) can also serve as identifiers.
- Duplicate identifiers inside one file cause an import error, and that record is not imported. Resolve them before you upload.
If a row has no reliable key, the import can create a new record when you meant to update an existing one. Rows like that belong in the browser-edit pile.
Run a small, reviewed import
For the rows that pass the table, use HubSpot’s import tool carefully:
- Choose the mode on purpose. Create and update does both. Create only ignores existing records. Update only updates existing records and ignores new ones. For a cleanup batch, Update only stops accidental creates.
- Protect existing values where needed. Selecting Don’t overwrite in the Manage existing values column updates a property only on new records and on existing records that never had a value for it.
- Treat blank cells as untested. A HubSpot community answer reports that empty cells do not clear existing values while non-empty cells overwrite them. That is community-reported behavior, not official documentation. Confirm it with your test batch.
- Fix mapping errors before importing. Errors appear on the Map columns in your file screen, where you can correct values.
- Import a small batch first. HubSpot’s import page does not describe a dry-run preview or an undo. Your first few rows are your preview. Open those records and check every mapped field.
- Know your rollback path before the full run. Restore CRM changes can roll records back to a point up to 14 days ago, including changes from an import: Settings > Data management > Backup & Restore > Restore > Restore CRM changes, then Source = Import. It requires Super Admin permissions and a qualifying paid tier, and each restore handles either created records or modified properties, not both. If you lack access, assume you have no undo and keep the test batch small.
When reviewed browser edits fit better
Some rows never belonged in an import. Common examples:
- The file and the CRM disagree on a job title, and you don’t know which is current.
- A contact has a new email at a new company, so the email-based match points nowhere.
- A record needs a note, an association or a status change that depends on reading its history.
Don’t resolve these by picking a value in the spreadsheet. Keep both values and decide with the record open. An exception sheet makes that review explicit:
| Record link | Field | Current CRM value | Proposed value | Source | Decision |
|---|---|---|---|---|---|
| (record URL) | Job title | Recruiting Lead | Head of Talent | Company team page, checked date | Pending |
Illustrative row only.
Fill in “Decision” only after someone has looked at the evidence. “Pending” is a valid final state for a row you can’t settle yet.
Illustrative workflow: preparing exception edits with Dassi
This is an illustrative workflow, not a tested HubSpot integration. Dassi is a browser agent that runs in the Chrome, Edge or Brave profile you already use, on accounts you’re already signed into. You describe a job in plain English, and Dassi pauses for actions you flag and for anything it can’t settle on its own. Approvals happen in the side panel or via Telegram.
A cautious first pass is read-only:
For each row in my exception sheet, open the record link in the CRM. Copy the current value of the named field into “Current CRM value.” Do not edit or save anything. If the record doesn’t open, or the field is missing, write that in “Decision” and move on.
After you review the sheet and mark decisions, a second pass can prepare the edits:
For rows marked “Approved,” open the record and enter the proposed value. Stop before saving each record and ask me to approve.
The CRM’s own rules still apply in the browser. For example, HubSpot blocks manual contact creation with an email that already exists. A browser agent doesn’t bypass that check, and you shouldn’t want it to.
Two things to know first. The model provider you configure processes the page content Dassi reads, so the data is not entirely local. And you remain responsible for each approved change, so check the record after saving.
What stays human
- Choosing which value is true when sources conflict.
- Deciding whether a partial match is the same person or company.
- Checking the test batch before the full import.
- Confirming you have rollback access before you rely on it.
Next step
Split your prepared file in two. Run the clean rows through a small Update only import and check every field on those records. Put the rest in an exception sheet. To prepare those exception edits for your approval in the browser you already use, install Dassi from the Chrome Web Store and start with the read-only pass.