The short answer
Import records into ERPnBox with duplicate checking switched on. It maps your spreadsheet columns to fields, then checks each row against existing records using your rules before writing it — skipping or blocking likely duplicates. Import a sample first, review the summary, and merge any historical dupes without losing their notes or activities.
Every clean CRM has a dirty secret: the mess didn't accumulate slowly. It arrived all at once, on a Tuesday, in a spreadsheet. Import is where duplicates are born, and no amount of tidying afterward is cheaper than not making the mess in the first place. This is the guide to importing thousands of records into ERPnBox without your database quietly forking into two of everyone.
How do you import records without creating duplicates?
You import with duplicate checking switched on. ERPnBox reads your spreadsheet, maps each column to a field, and before it writes a row it checks that row against your existing records using your duplicate manager rules. Likely matches are skipped or blocked, not silently added. The import finishes clean.
The important word is before. Plenty of tools let you import first and clean up later. That is the expensive order. Every duplicate that lands is a lead two reps now call, a contact your email sends to twice, a deal counted once in the pipeline and once again in the forecast. Checking at the door costs one setting. Checking after the party costs a week.
Why is import the moment duplicates are born?
Because a spreadsheet has no memory of your database. The person exporting a list from an old system, a trade-show scanner, or a marketing tool has no idea half those people already exist in your CRM. Volume hides the overlap. Ten rows you can eyeball; ten thousand you cannot. So the safeguard has to live in the import itself.
- The same person from two sources — the event list and the newsletter list both hold the same email.
- Re-imports — someone runs last month's file again "just to be safe" and doubles a slice of the database.
- Format drift — one file has "Acme Inc." and yours has "Acme Incorporated"; a field-match rule catches what an exact-string check misses.
- No unique key — the source has no shared ID with your CRM, so matching has to happen on the human fields: email, phone, name plus company.
What is the right import workflow, step by step?
Four moves: map your columns to fields, choose the duplicate rule that decides a match, tell the import what to do with a match, then review the summary before you trust the result. Skipping the review is skipping the point. The workflow is deliberate so the database stays honest.
| Step | What you do | Why it matters |
|---|---|---|
| Map fields | Match each spreadsheet column to a CRM field | A wrong map puts a phone in the notes and breaks matching on phone |
| Set the match rule | Pick which field(s) define a duplicate — email, phone, name + company | This is your definition of "the same person" |
| Choose the action | Skip likely dupes, or block the row entirely | Decides what happens the instant a match is found |
| Review the summary | Read how many imported, skipped, and flagged | Your last chance to catch a bad map before it's live |
Import a sample of 20 rows first. Run a tiny slice, read the summary, confirm the fields landed where you meant and matching behaved as expected — then run the full file. Twenty rows tells you everything ten thousand would, at none of the cleanup cost.
What if duplicates already slipped in?
Then you clean up rather than block, and the duplicate manager does it without losing history. It surfaces the pairs your rules flag, and a merge folds two records into one — keeping the activities, notes, and attachments from both sides. Nothing gets orphaned. The survivor carries the full story.
That safety net is exactly why the import gate matters. Merging is clean but manual — someone reviews each pair. Prevent a thousand duplicates at import and you have a thousand merges you never do. Prevention scales; cleanup does not.
How do you keep the database clean after the import?
Turn the one-time discipline into a standing one. Build a saved view that shows recently imported records so a reviewer can scan the batch. Watch for the fields that matter — a field history trail tells you who touched what after the fact. And keep your match rules current, because a dedupe rule is only as good as the fields it checks.
You configure all of this — the field map, the match rule, the saved view. You don't code any of it. Once import is clean at the door and the merge tool is there for anything historical, a clean CRM stops being a project and becomes the default state. And a clean database is the one thing every report, every chart view, and every rep quietly depends on.
Import your first list — clean from the start
Map your fields, switch on duplicate checking, and bring your data over without doubling it. Start free.
Start freeFrequently asked questions
Does import block duplicates or just warn me about them?
Both are available, and you choose per import. You can set likely matches to be **skipped** — imported rows that match an existing record are quietly left out — or you can **block** them so the row isn't written at all. Either way, the check happens ==before the record is created==, driven by your [duplicate manager](/features/crm-duplicate-manager) rules.
What field does duplicate checking match on?
Whatever you define. Email is the usual anchor, but you can match on **phone**, or on a combination like **name plus company** when the same person appears without a shared email. The rule is yours to set — that flexibility is what catches format drift like "Acme Inc." versus "Acme Incorporated."
What happens to records that already exist as duplicates?
Use the [duplicate manager](/features/crm-duplicate-manager) to find and **merge** them. Merging combines two records into one and ==keeps the activities, notes, and attachments from both==, so no history is lost. Import prevention stops new dupes; the merge tool cleans up the ones already there.
Can I import a sample before running the whole file?
Yes, and you should. Run a **small slice first** — twenty rows is plenty — then read the import summary to confirm your field map is right and duplicate checking behaved as expected. Once the sample looks correct, run the full file with confidence. It's the cheapest insurance in the whole workflow.
How do I keep imports clean over time, not just once?
Build a [saved view](/features/crm-filters-and-saved-views) of recently imported records so a reviewer can scan each new batch, and keep your match rules current as your data grows. **Field history** gives you an audit trail of who changed what, so a bad import is easy to trace and reverse.
