How to Use Make Without Creating Duplicate Records

Why Make workflows create duplicate records

A duplicate record exists when multiple system records represent the same real-world person, company, transaction, or service event. In Make, duplicates usually appear because the scenario treats every incoming event as new rather than deciding whether the event belongs to an existing business record.

This can happen even when every module is configured correctly. A form submission may arrive twice, two scenarios may process the same contact, or an email may contain different capitalization and spacing from the value already stored in the CRM. The technical steps run, but the underlying identity logic is incomplete.

Create-first logic

The most direct risk is a create action immediately after a trigger. If a lead form, checkout, or webhook sends data into Make and the next step creates a CRM record, the scenario has no opportunity to identify a prior record.

Create-first logic is sometimes appropriate for objects that have a guaranteed unique external ID. For people and companies, however, the workflow usually needs a lookup and decision step first.

Multiple creation paths

Duplicates often result from several individually reasonable workflows. A contact might be created by a website form, an ecommerce order, a support request, and a manual import. If each path can create the same contact independently, the organization has multiple authorities for one record.

Adding more filters to each scenario does not solve the ownership problem. The creation paths need a shared rule for identifying and updating the master record.

Weak or inconsistent identifiers

Names are rarely reliable identifiers. A person may submit a different name, a company may use a trading name, and a shared email address may represent more than one person. Email, phone number, company domain, platform IDs, and order IDs can all be useful, but their reliability depends on the object and the process.

A good matching rule states which identifier is preferred, which alternatives are acceptable, and when the workflow must stop rather than make an uncertain match.

Start with ownership, not modules

Before building a Make scenario, define the source of truth for each important object. The source of truth is the system whose record should be treated as authoritative when other tools contain conflicting or incomplete information.

For example, a CRM may own contacts and companies, an ecommerce platform may own orders, and a support platform may own tickets. Make can move information between these systems, but it should not allow every connected system to create and independently govern the same object without a clear rule.

Ownership also needs to be defined at field level when systems share an object. For instance, the ecommerce platform may own an order status while the CRM owns sales ownership and lifecycle stage. Without this distinction, a sync can overwrite valid changes or create conflicting update loops.

Use a search-before-create decision sequence

The safest general pattern for preventing duplicates is not simply “search, then create.” It is a sequence that validates the event, normalizes the inputs, searches for a match, and handles uncertainty explicitly.

The decision should not be reduced to a binary match or no match when the data is ambiguous. A possible match may require human review, especially when a shared inbox, household phone number, or generic company domain is involved.

Match rules should reflect the object

Different objects need different identity rules. A contact may use a normalized email as the primary key, with phone as a supporting identifier. A company may use a verified external ID or domain, with legal name as supporting evidence. An order should normally use the order ID supplied by the ecommerce platform. A ticket should usually retain the ticket ID from the support system.

Do not use a broad name search as permission to update the first result. The rule should define what counts as a confident match and what happens when several records qualify.

Normalize data before comparing it

Normalization reduces false non-matches caused by formatting differences. Common examples include converting email addresses to a consistent case, removing unnecessary spaces, standardizing phone numbers, and applying a defined format to company domains.

Normalization does not prove that two records are the same. It only makes comparison more consistent. A normalized company name may still match several legal entities, and a phone number may be shared. Treat normalization as preparation for a decision, not as the decision itself.

Store the normalized value where it can be reused. If every scenario performs its own transformation, small differences will eventually appear. A shared field standard, reusable sub-scenario, or controlled data service can make matching logic easier to maintain.

Protect against retries and parallel runs

Duplicate prevention must account for timing, not only field values. Webhooks can be delivered more than once, a source system can retry after a timeout, and two events for the same person can be processed almost simultaneously.

This creates a race condition. Two scenario runs search before either run has completed its create action, both find no match, and both create a record. The search-before-create pattern is necessary, but it may not be sufficient when concurrent runs are possible.

Useful safeguards include preserving the source event ID, checking whether that event has already been processed, limiting concurrency where appropriate, and using a unique external key when the destination system supports one. The exact control depends on the systems involved and the guarantees they provide.

Example: a repeated lead submission

Consider a hypothetical business that receives a lead from a form and sends it to Make. The form provider retries the webhook after a slow response. Without an event ID check, Make receives two valid-looking payloads. Both search the CRM at nearly the same time and both find no contact.

A safer workflow stores the source event ID, rejects an event already processed, normalizes the email, searches the CRM, and creates the contact only when the event is new and no confident match exists. If the same person submits again through a different form, the email match can route the event to the existing contact instead of creating another one.

Separate matching from enrichment and follow-up

Many duplicate problems occur because record creation, enrichment, notifications, and follow-up are placed in one uninterrupted path. When the creation decision is unclear, downstream actions may run against the wrong record or run twice.

Make the identity decision a distinct stage. Once the workflow has a confirmed record ID, later steps can update fields, create a task, associate an order, or send a notification using that stable ID. This is safer than repeatedly searching by name or email in later modules.

It also makes ownership visible. The workflow can log whether it updated an existing record, created a new one, or routed an ambiguous case for review. That record of the decision helps operations teams diagnose failures without reconstructing every run manually.

Use Make and the CRM for different controls

Make is well suited to cross-system orchestration. It can capture source context, transform fields, route events, look up records, and coordinate actions across tools. The CRM or other system of record should enforce the rules that belong inside that system, such as native duplicate controls, required fields, ownership, merge governance, and lifecycle rules.

Neither layer should be expected to solve every problem alone. Make cannot compensate for an undefined CRM data model, and a CRM cannot reliably infer the identity of an event that arrives without a usable external key.

For teams reviewing their broader CRM architecture and lead management, duplicate prevention should be treated as part of the operating model rather than a small scenario patch.

Monitor the decisions, not just the errors

A scenario can show no technical errors while still creating bad records. Monitoring should therefore include business outcomes, not only failed module executions.

• How many events resulted in an update, create, link, or review queue?
• Which source systems generate the most uncertain matches?
• How often are the same external event IDs received again?
• Which scenarios can create the same object?
• Are records being updated by the intended system and owner?

Review these signals after changes to forms, fields, CRM rules, imports, or connected applications. Duplicate prevention is an operating control that needs maintenance as the business process changes.

When the workflow needs a wider redesign

If several scenarios can create the same records, adding another filter may only hide the underlying problem. A wider review is appropriate when teams do not know which system owns an object, when reporting depends on merged data, or when cleanup has become a recurring operational task.

The review should map the real process, inventory creation and update paths, define record ownership, standardize identifiers, and then redesign the automation. A Make automation implementation should support that operating model rather than become another isolated integration.

A relevant example of this type of thinking is a connected import design that matches existing CRM records and creates related records only when needed. The ConsultEvoHubSpot Multi-Object Sales Import and CRM Association SystemAn example of matching existing records and preserving relationships across connected CRM objects.→

More tools do not automatically create a better operating system. The useful question is whether each automation has a defined job, a visible owner, and a safe response to uncertain data.