How to prevent duplicates in Attio

Last checked September 7, 2026 · Deduptio is our product. Every claim about another tool comes from its public site or documentation and is linked in place — tell us if something is out of date.

Prevention is a write-path problem, not a data problem

The usual instinct is to treat duplicates as a mess to be tidied, run a cleanup, and be surprised when the backlog is back in a quarter. It comes back because the cleanup did not touch the thing that created it. A duplicate is not a defect in your data; it is the output of a write path that had no way to recognise the record already existed.

So the useful question is not "how do I stop duplicates" but "what writes records into this workspace, and which of those writes can tell an existing record from a new one". In practice there are six, and they are not equally dangerous.

1. Imports: map the unique attribute

A single unmapped import is the largest duplicate event most workspaces ever have, because it duplicates an entire object in one action rather than one record at a time. Attio will match rows against existing records if you tell it what to match on; give it nothing and every row becomes a new record.

Map email address for people and domain for companies, and do it before the import runs rather than discovering it afterwards. Full detail, including what to do when the import has already landed, is in duplicates from a CSV import.

2. Email sync: the one that runs while you are not looking

Attio can create person and company records from inbound mail. That is a feature — it is most of why the activity history is worth having — but it is also a write path with no judgement: anyone who emails anyone becomes a record, whether or not a record for them already exists under a different address.

Two habits keep it from being a problem:

• Pause it during migrations and large imports. Sync creating records in parallel with an import loading the same people is the single most common cause of duplicates in a young workspace, and the resulting pairs are the nasty kind — the record with the activity is the one sync created, and the record with the data is the one you imported.
• Be deliberate about whose mailboxes are connected. Every connected mailbox is another source of automatic record creation. A shared support inbox will generate records for every person who ever wrote in.

3. Forms and inbound lead capture

A form is a write path that lets a stranger choose the identifier. Someone who exists in your workspace as rachel@acme.com signs up with a personal address, and exact matching on email — the strongest signal a person record has — has nothing to match. This is not preventable by configuration; it is preventable by design:

• Search before you create. Any integration writing form submissions should look for an existing person on email, and where you can, on name plus company domain, before creating one.
• Where the form feeds a list or a lead object rather than creating people directly, the duplicate never reaches the People object in the first place.
• Ask for a work email where the question is not intrusive. It costs a conversion point and saves a merge.

More on why people duplicate specifically, and which secondary signals hold when email moves, is in find duplicate people in Attio.

4. Integrations and automations

Zapier, Make, an enrichment tool, a sequencer — anything with a "create record in Attio" action will happily create a second one on every trigger. Both Zapier and Make expose create-or-update actions against Attio, and enrichment platforms such as Clay upsert on a unique attribute rather than creating blindly. Use them, and audit the automations you set up before you knew to.

The important caveat: this governs only the records flowing through that automation. It has no effect on imports, on email sync, or on the human typing into Attio. See Zapier and Make dedupe and Clay for where each line actually falls.

5. Your own API writes: assert, do not create

If you write into Attio from a script, a webhook or a backend service, the highest-value single change is to stop calling create. Asserting with a matching attribute updates the record already holding that email or domain, or creates one if nothing matches — and it does so atomically, so two concurrent writes cannot both conclude the record does not exist yet. The endpoints, the costs and what the API will not do for you are in Attio duplicate detection with the API.

6. People

The one with no technical fix. Someone in a hurry types "Acme", does not see the existing "Acme Ltd", and creates it. Two teammates add the same account within a week. The realistic answer is not a policy nobody reads: it is making the duplicate visible quickly enough that whoever created it is still around to say which record is right.

What unique attributes cannot do

Everything above is exact matching, and it is worth being clear about where exact matching stops:

• A person whose email changed. They changed jobs; the identifier moved with them. Exact matching sees two different people.
• A company on a second domain. Rebrands, acquisitions, country domains, and the marketing site that is not the corporate one. See find duplicate companies.
• A record with no identifier at all. No email, no domain — nothing to assert on, so every write creates.
• Custom objects and deals. Whatever you assert on has to be a stable business identifier you actually populate, and for deals there usually is not one.

What prevention cannot do

This is the part worth saying plainly, because a workspace that has just fixed all six write paths still has exactly as many duplicates as it did yesterday. Prevention governs future writes. It does not merge anything, it does not look backwards, and asserting on email will never join two records that already exist under two different emails.

The realistic model is a floor and a rate. Prevention lowers the rate at which new duplicates arrive. A cleanup pass lowers the floor. You need both, and doing the cleanup first without the prevention is how a workspace ends up being cleaned twice.

The order to do this in

1. Fix imports first. Highest volume per incident, and the fix is one mapping in a dialog you are already in.
2. Scope email sync, and pause it before any migration or bulk load.
3. Audit every automation with a create-record step and switch it to create-or-update.
4. Assert in your own code, everywhere records are written.
5. Then clean up what is already there — and only then, because a cleanup run before step 2 gets re-dirtied by the sync you had not paused.
6. Put a recurring scan on it, so the ones that get through the six paths surface in days rather than at the next audit.

Where Deduptio fits

Deduptio is not prevention, and it would be dishonest to sell it as such: it does not sit in front of Attio's write path and it cannot block a record being created. What it does is make the gap between a duplicate arriving and someone seeing it small enough that prevention gaps stop compounding.

• Scheduled scans — daily or weekly, across every object that has a match rule. Scans are read-only and never merge anything.
• Email only when something is new. A scheduled scan that finds no new groups sends nothing, so a quiet inbox means the write paths are holding.
• Rules are the scope control. An object with no match rule is skipped entirely, which is how you keep automation pointed at the objects that matter.

Automation is a Pro feature; the details are in the automation documentation, and rule design is in rules and scanning.

Related

• Duplicates from a CSV import — the single largest preventable source.
• Duplicate detection with the API · Zapier and Make dedupe
• Find duplicate people · Find duplicate companies
• Attio deduplication: the complete guide · All guides