Direct answer
Duplicates created by an automation come from a short list of causes: two triggers watching the same source, a retry or replay after a timeout when the first attempt had in fact worked, schedules that overlap or run slowly, a step that matches records by name instead of by a stable identifier, and date boundaries in scheduled pulls. Merging the duplicates first removes the evidence. Before you clean anything, find out whether one event ran twice or two events each created a record. Then fix that cause, make the step safe to run twice, and only then merge what is left. This page is about the symptom and its causes. For preventing duplicates at the point of entry, see prevent duplicate leads in your CRM.
Same event, two runs, or two events, two records?
Take one pair of duplicates and compare them. If the two records carry the same source event, for example the same submission or the same message, the automation ran twice for one event. If they come from two separate events that describe the same person or order, the automation ran correctly twice and the problem is recognising that they are the same thing. The first is a trigger or retry problem. The second is a matching problem. The fixes are different, so settle this before anything else.
Two triggers on one source
The most common structural cause is two things watching the same source. A form connected through its own integration and also through an email notification. Two connected accounts in the same tool. A copy of the automation someone made for testing and left switched on. Each trigger fires once, so the record is created twice. Look at every automation that could create this kind of record, not only the one you suspect.
Retry or replay after a timeout
When a step waits for an answer and the answer is slow, the tool may try again. If the first attempt actually succeeded and only the reply was lost, the retry creates a second record. The same happens when someone replays a failed run by hand without checking what had already been done. You cannot assume a retry is safe, and no tool can promise a step will be delivered exactly once. The design question is what the step does if it is asked to do the same thing twice.
Overlapping schedules and slow runs
A scheduled run that pulls new records can start again before the previous run has finished, especially when the source has grown. Both runs then see the same records and both create them. Check whether runs can overlap, and what a run does when the previous one is still working. Also check whether a schedule was copied so that two versions exist.
Matching on name instead of a stable identifier
If a step decides whether a record already exists by comparing names, small differences make it decide no: a different spelling, an extra space, a nickname, a company name with or without its legal ending. It creates a new record each time. A stable identifier, such as an ID the source system assigns or an email address treated consistently, is a better basis. Even then, agree which field is the key. The reasoning behind this choice is set out in system of record for integrations.
Time-zone and boundary effects on scheduled pulls
A scheduled pull that asks for records changed since a moment in time can pick the same records up twice if the two systems disagree about time zones, or if the boundary is inclusive on one run and again on the next. Records sitting exactly on the boundary are read twice. Check how the pull decides where to start, and whether that point is recorded in one consistent time reference.
Make the step safe to run twice
The dependable fix is to design the step so that repeating it does no harm. In plain terms: before creating a record, the step looks for one with the same stable key, and updates it if found instead of creating another. Store the key from the source on the new record so the next run can find it. This does not make delivery happen exactly once. It makes a repeat harmless, which is what you actually need. Check the same rule on the receiving side even when the sending side is meant to be careful.
Clean up after the cause is fixed
Only once the cause is fixed should you remove the duplicates already created. Decide which record survives, keep the history from both, and record what you merged. The steps are in merging duplicate CRM records. If you merge before fixing, the automation will simply create the next batch.
Where LATYNEX fits
If the step needs rebuilding with a stable key and a check before it creates anything, a small first job like this can be scoped as the Automation Sprint (€1,690, fixed scope), agreed in writing before work starts. See Workflow Automation & Systems Integration.
When LATYNEX is not the right fit
It is not the right fit for a one-off duplicate that a person can merge by hand, or when the cause is a single extra automation that you can simply switch off. It is also not a takeover of an undocumented set of automations: work starts from a description of what should happen. Nothing here claims that any particular tool removes duplicates for you.
Questions
How can I tell whether it ran twice or two events created two records?+
Compare a pair of duplicates. If they carry the same source event, one event ran twice. If they come from two separate events about the same person or order, it is a matching problem.
Why did a retry create a duplicate?+
The first attempt may have worked and only the reply was lost. The retry then did the same thing again. The step needs a check for an existing record before it creates one.
Can an automation guarantee exactly-once delivery?+
You should not rely on that. Design the step so that repeating it is harmless, by looking up a stable key before creating anything.
Should I merge the duplicates first?+
No. Find and fix the cause first, otherwise new duplicates keep arriving and you lose the evidence of what happened.
What is a stable identifier?+
A value that identifies the same record every time, such as an ID assigned by the source system. Names are a weak key because spelling varies.