When a Make run is green but CRM records are duplicated, what gets fixed first?

Questions
1

:bullseye: What is your goal?

When a Make run is green but CRM records are duplicated, what gets fixed first?

:thinking: What is the problem & what have you tried?

For folks who build or maintain Make scenarios for clients: when a run is green but the CRM ends up with duplicate or uncertain records, what usually has to happen first: clean up the bad records, change the scenario so it does not happen again, or figure out what is safe to replay?

3

Hello,

Architecture. If the scenario creates duplicates, it means something wasn’t designed well.

Have a nice day,
Michal

4

I would stop the scenario first, then fix the logic that lets duplicates through. Cleaning the CRM before that just means the same thing can happen again.

The usual pattern is: search CRM first using the safest unique key you have, update if found, create only if nothing is found. I would also store the source record ID somewhere in the CRM if possible, so replaying a Make run cannot create a second record.

After that, clean up the existing duplicates and only replay the records you can prove were not already created.

5

I would fix the idempotency path first, before doing any CRM cleanup.

The check I use is:

  1. Pick the record key that should be unique every time: email, external ID, or a composite key.
  2. Search/read by that key before any create step.
  3. Only create when the search returns no match; otherwise update the matched record.
  4. Add one small replay guard: log the source event ID plus the matched CRM ID, so retries/webhook replays cannot quietly create a second record.

The trap is that a Make run can be fully green while still being logically non-idempotent. If the create module can run without first proving “no existing record for this source event/customer”, the scenario will keep passing while duplicates grow.

6

That makes sense. The part about logging the source event ID plus the matched CRM ID is the bit I was trying to make more concrete.

In a tiny fictional “do not replay yet” card, I’d mark reads/transforms as safe, but hold deal/task creation and reporting-row appends until each has an event-keyed search/update path instead of a new create.

Does that miss the main thing you’d check before touching the CRM, or is that basically the right first-pass shape?