The file is cleaned. The columns are mapped. The business is waiting. Someone from sales has already asked when the records will be live, and marketing wants the campaign launched as soon as the import finishes.
That's the moment when the import data wizard stops feeling like a friendly interface and starts feeling like a risk surface.
Most CRM damage doesn't come from dramatic system failures. It comes from ordinary imports done too quickly. A lead list lands in Salesforce without the right owner logic. A HubSpot contact import creates a second version of key accounts. A product update rewrites lifecycle properties that should have been left alone. Nobody notices immediately, because the wizard says the job completed.
Then the mess starts. Reports shift. routing breaks. nurture flows fire on the wrong people. Reps lose trust in the CRM and go back to spreadsheets.
I've seen this often enough that I treat imports less like admin work and more like change management. The wizard matters, but the essential discipline sits around it. Good teams protect the database before a single row is uploaded. They know how to prepare a source file, how to choose matching logic, and how to audit the outcome instead of assuming success because a progress bar reached the end. If your current priority is stronger CRM hygiene, this guide on improving data quality is worth keeping close.
The Moment of Truth Before the Import
An Ops manager is staring at a CSV pulled from an event platform, enriched by a GTM team, and approved by sales leadership. It needs to land in Salesforce before the next outbound push. The file looks harmless. Names, titles, email addresses, account names, owner notes. Standard stuff.
But one question changes everything. Is this a net new import, an update, or a mix of both?
If the answer isn't clear, the import data wizard becomes dangerous. A mixed file with weak matching logic can create duplicates, overwrite trusted values, and trigger automations that were designed for entirely different scenarios. In HubSpot, that might mean lifecycle confusion or enrolment into the wrong workflow. In Salesforce, it can mean bad campaign attribution, broken lead assignment, or records pushed into the wrong record type.
Practical rule: If you can't explain what should happen to every major column before the import starts, you're not ready to import.
The teams that stay out of trouble do one thing consistently. They slow down before they speed up. They treat the import as part of the broader RevOps system, not as an isolated task performed by whoever has permissions.
That mindset matters most when the import is politically visible. Event leads. partner lists. product migrations. historical backfills after an integration change. These aren't simple uploads. They touch revenue reporting, routing, segmentation, and customer experience all at once.
The import data wizard is only as good as the thinking behind it. That's why the work that follows matters more than the button labelled Finish.
Pre-Import Data Preparation The Real Work Happens Here
Preparation decides whether the wizard feels easy or punishing. Most failed imports were already failed in the spreadsheet.
Build one source of truth file
Start with a master sheet. Not three versions in Slack, not a forwarded CSV with hand-edited columns. One controlled file that becomes the source of truth for the import.
That file should include the final intended values, the target object, and any notes on transformation logic. If an import goes sideways, this sheet becomes your rollback reference and your audit trail. It also keeps sales ops, marketing ops, and admins from working off different assumptions. Teams handling larger projects should also follow disciplined data migration best practices, because import errors rarely stay isolated.
A strong source file usually includes:
- Stable identifiers: CRM record IDs, external IDs, or other fields used for matching.
- Controlled picklist values: Final approved values for country, state, lifecycle stage, lead source, status, and owner-related fields.
- Helper columns: Notes for formulas, concatenations, validation flags, and exception handling.
Standardise before you map
Most import problems come from inconsistency, not missing data. “United Kingdom”, “UK”, and “U.K.” are three different values to a CRM if your field expects one specific format. The same goes for provinces, job functions, business units, and dates.
Use spreadsheet functions to normalise values before the import. Don't rely on the wizard to interpret intent. It won't.
Focus on these fields first:
- Names and account labels: Clean trailing spaces, odd capitalisation, and placeholder text.
- Dates: Match the exact format your CRM expects.
- Phone numbers: Choose a standard pattern and apply it consistently.
- Country and region fields: Align to existing CRM conventions, not what the vendor file happens to use.
- Boolean or yes/no values: Convert variants into the exact accepted value set.
Clean data isn't data that looks tidy to a human. It's data that behaves predictably inside automation, reports, and routing logic.
Create an external ID before you need one
If you only take one strategic step, make it this one. Add a unique external ID whenever the business process allows it.
In Salesforce, external IDs are one of the safest ways to support updates, upserts, and future integrations without depending on mutable fields like email address or company name. In HubSpot, a custom unique property can play a similar role when you need more control than default email matching gives you.
This matters most when records can change ownership, email, name, or structure over time. A stable identifier gives you a reliable key for future imports and reduces guesswork during deduplication.
Enrich carefully, not blindly
Pre-import enrichment can improve routing, segmentation, and account prioritisation. It can also inject noise if you enrich faster than you validate. I like using tools such as Clay before import when the goal is to fill meaningful gaps, validate companies, or prepare GTM-ready fields for territory or persona logic.
Use enrichment with restraint:
- Add only fields your teams will use.
- Separate vendor-sourced values from first-party values when trust levels differ.
- Flag uncertain records for review instead of forcing them through.
A bigger file is not a better file. Imported records should support decisions, not just increase row count.
A Strategic Walkthrough of the Import Wizard
The user interface changes between Salesforce and HubSpot. The strategic choices don't. Every import data wizard asks the same underlying questions. What kind of record is this, how should the system recognise it, where should each value go, and what should happen if the data conflicts with what's already there?
Choose the object with intent
This sounds basic, but it's where many teams start wrong. Importing into leads instead of contacts, or contacts instead of a custom object, creates downstream cleanup that's harder than the original job.
In Salesforce, the object decision affects assignment rules, record types, page layouts, automation, and reporting. A lead import is not just a temporary holding area if your business converts quickly or routes at the account level. In HubSpot, importing contacts without considering associated companies or deals can flatten account context and leave GTM teams with records that look complete but lack relationship structure.
Ask two questions before selecting the object:
- Where does this record belong in the lifecycle right now
- What process should start the moment this record exists
If the answer is fuzzy, stop there.
Treat field mapping like architecture
Mapping is where strategic imports separate from careless ones. The goal isn't merely to avoid errors. The goal is to preserve data meaning inside the CRM.
A field map should answer all of the following:
- Is this source value landing in the canonical field
- Will the destination field support reporting and automation
- Could this import overwrite a better existing value
- Does this value belong in a custom field, a note, or nowhere at all
Teams often map because a field exists, not because it should be used. That's how CRMs fill up with duplicate concepts across slightly different properties.
If you're importing into Salesforce and the data model is already complex, it helps to review a disciplined approach to Salesforce field mapping. The issue usually isn't the wizard. It's mapping a business concept into the wrong place and locking in confusion for months.
Field mapping is policy, not plumbing. Every mapped column makes a decision about how the business will read, route, and trust that data later.
Decide what not to import
Good operators leave columns out all the time. If a source file contains messy free-text values, obsolete statuses, or one-off notes with no operational use, don't force them into the CRM.
That decision is often smarter than creating a custom field under deadline pressure. New fields should exist because the business needs them repeatedly, not because a spreadsheet happened to include a column once.
A simple filter works well here:
| Keep It | Question to Ask |
|---|---|
| Core operational field | Will sales, marketing, or service use this in workflow or reporting |
| Supporting context | Should this live in a note, activity, or related object instead |
| Disposable noise | Is anyone going to trust or use this after import |
Handle platform-specific constraints early
Salesforce and HubSpot each have their own traps.
In Salesforce, watch for record types, required fields, active picklist values, owner permissions, validation rules, lead source conventions, and automation that fires on create or update. If you're importing related records, sequence matters. Accounts may need to exist before contacts. Parents may need to exist before child objects.
In HubSpot, required properties, unique property behaviour, association logic, and workflow enrolment criteria need a close look. Imports can look successful while still producing weak outcomes if company associations are skipped or if properties used in reporting aren't populated consistently.
Use the source sheet to transform, not the wizard to improvise
When a value needs concatenation, splitting, or normalisation, do it in the source file first. Formula columns are safer than making assumptions mid-import. If first and last name need to become a display field, or if region logic needs a helper column, build it outside the wizard where reviewers can inspect it.
That approach creates transparency. It also makes reruns cleaner because the transformation logic stays visible in the working file rather than in someone's memory.
Advanced Deduplication and Validation Strategies
Duplicates don't just clutter the CRM. They split history, distort attribution, confuse reps, and weaken segmentation. One person becomes two records. One account becomes three reporting paths. Then someone asks why the dashboard doesn't match reality.
Basic duplicate prevention helps, but it won't solve most real-world imports. Matching only by email can work for straightforward contact updates. It fails quickly when you're dealing with shared inboxes, changed work emails, acquisitions, subsidiaries, or old records that were created before your current standards.
Match on business reality, not convenience
The best deduplication rule depends on how your GTM process works. If one person should only ever exist once regardless of account movement, a stable external ID is stronger than email. If the data comes from multiple vendors and identifiers are unreliable, a composite key may be the practical fallback.
Here's how I evaluate the main options.
| Matching Rule | Best For | Potential Pitfall |
|---|---|---|
| Email address | Straightforward contact imports where email is trusted and current | Misses duplicates when emails change or shared inboxes are used |
| CRM record ID | Updating records already exported from the CRM | Useless for net new records and risky if IDs were copied incorrectly |
| External ID | Ongoing syncs, migrations, and cross-system record management | Fails if the source system never maintained a stable unique key |
| First name plus last name plus company | Legacy lists and event files without dependable IDs | Creates false matches for common names and misses naming variations |
| Company domain plus person name | B2B prospecting and account-based imports | Breaks on holding companies, consultants, and contacts using personal domains |
If the import matters to revenue reporting, don't settle for the easiest matching rule. Use the rule that reflects how the business identifies a real-world entity.
Separate duplicate prevention from duplicate resolution
These are different jobs. Prevention stops new clutter from entering. Resolution decides what to do when the wizard finds a possible conflict.
In Salesforce, duplicate rules and matching rules can block creation, allow it with an alert, or permit controlled review depending on configuration. In HubSpot, de-duplication logic is more opinionated in some areas and more limited in others, especially if your process depends on custom unique keys and complex associations.
That means your import strategy should answer two separate questions:
- How will the system recognise a likely match
- What should happen when a likely match is found
Sometimes the right answer is update. Sometimes it's create anyway because the relationship context is different. Sometimes it's hold the row outside the import and review it manually.
Use a test batch to provoke failures on purpose
I don't trust a full import until I've run a small test batch that includes records likely to break. Include problem children on purpose. Bad state values. Missing required fields. Records that should match an existing contact. Rows that trigger validation logic.
This is how you expose hidden assumptions without turning a production import into a support incident.
A useful test batch often includes:
- Known duplicates: Records that should update, not create.
- Edge-case formatting: Dates, phone values, and picklists with the highest chance of rejection.
- Automation-sensitive rows: Records that would trigger assignment, scoring, lifecycle movement, or campaign entry.
- Relationship complexity: Contacts tied to existing accounts, or imports that depend on parent-child integrity.
Read the error log like an operator
Error logs tell you where your process design is weak. Don't patch rows one by one in the wizard if the pattern points to a broader issue in the source file.
Look for repeated failure types:
- Validation rule failures usually mean the import doesn't satisfy business logic that already exists for good reason.
- Picklist mismatches point to standardisation problems.
- Required field errors usually expose bad assumptions about what the object needs in your current architecture.
- Permission or ownership errors often mean the importing user lacks the right scope or the file references invalid users.
Fix these in bulk in the source file, then rerun the corrected batch. Manual one-off editing inside the platform creates inconsistency and weakens your audit trail.
Post-Import Audits and Automation Checks
The import isn't done when the wizard says complete. It's done when the data behaves correctly inside the system.
Start with a containment check
Before anyone celebrates, create temporary list views, reports, or filtered saved views that isolate the imported records. Use an import tag, created date, source label, or batch identifier so you can see exactly what landed.
In Salesforce, that might be a temporary report filtered by created date, lead source, campaign, or external ID prefix. In HubSpot, a filtered view using import source and key properties gives you a quick read on whether the records are complete and segmented correctly.
Review for obvious failures first:
- Blank critical fields: Owner, lifecycle stage, account association, source, status.
- Unexpected value patterns: Wrong country labels, broken names, placeholder text.
- Wrong object outcomes: Records created where updates were expected, or vice versa.
Check whether records were created or updated as intended
A technically successful import can still be strategically wrong. If you expected updates and got net new records, you've just introduced duplicate risk. If you expected new records and the system updated old ones, you may have overwritten trusted information.
Run a simple post-import comparison against the source sheet. Confirm that the intended rows made it in and that the key matching behaviour worked as planned.
Don't audit the whole file row by row. Audit the records that would hurt most if they were wrong.
That usually means enterprise accounts, active opportunities, named accounts, high-priority territories, and records tied to current campaigns.
Verify automations with live examples
Many teams halt their efforts too soon. Data in the right field is only half the job. The CRM and marketing automation stack still has to respond correctly.
Test what should have happened after import:
- Lead or contact assignment: Did territory rules, owner assignment, or queue logic place the records with the right team?
- Lifecycle movement: Did status fields or stage logic shift records in the intended way?
- Campaign or workflow entry: Did the right contacts enter the correct nurture or operational workflow in Account Engagement or HubSpot?
- Scoring and enrichment dependencies: Did any score updates, routing branches, or sync processes behave unexpectedly?
Use a small set of known test records for this check. Open the record. Read the timeline. Confirm the automation path. Don't assume a workflow ran because the field values look close enough.
Close the loop with documentation
Once the batch is confirmed, document what happened. Capture the source file version, mapping decisions, matching logic, import user, date, and any exceptions handled outside the main run.
This is operational memory. Without it, the next import starts from scratch and repeats the same mistakes under a different deadline.
From Data Import to Revenue Operations Excellence
Teams often treat the import data wizard like a utility. It's more important than that. It sits at the entry point of your revenue system.
Every import shapes what sales sees, what marketing can segment, what leadership trusts in reporting, and what customer-facing teams do next. If the data lands badly, every downstream process inherits the problem. If it lands cleanly, the rest of the GTM engine has a fair chance to work as designed.
That's why strong RevOps teams build import discipline into normal operating practice. They prepare source files carefully. They choose matching logic based on business reality. They audit outcomes after the upload instead of trusting the interface. They know that CRM quality is not maintained by good intentions. It's maintained by repeatable operational standards.
This matters beyond ordinary lead lists. The same discipline applies when importing target account data, syncing partner records, onboarding acquired datasets, or bringing in external opportunity intelligence from a government RFP database. The source may change. The standard shouldn't.
Mastering the import data wizard won't make your RevOps function glamorous. It will make it dependable. And dependable systems are what let B2B teams scale without losing trust in their data.
If your team is dealing with messy imports, CRM duplication, Salesforce or HubSpot migration risk, or post-import automation issues, MarTech Do can help you clean up the process and build a more reliable RevOps foundation.
