Typeform, HubSpot, Slack: Where Duplicate Writes Start

Duplicate Slack alerts are usually not a Slack problem

In my recent audits, teams often notice the symptom at the end of the lane and blame the last tool in the chain.

I see this exact misdiagnosis repeatedly in live Typeform, HubSpot, and Slack lanes: the message is duplicated at the edge, but the control failure started upstream.

The most common example:

• Typeform submission comes in,
• HubSpot gets updated,
• Slack sends two or three notifications,
• team says "Slack duplicated the message."

In most cases, Slack did not start the duplicate. The duplicate started earlier, when the business event was not keyed correctly, the Make.com branch order was wrong, or replay logic allowed the notification step to run again.

One inherited B2B SaaS intake lane I audited had 14 retried submissions that generated 41 Slack notifications and 9 duplicate HubSpot contact side effects over one week. The team first blamed Slack. The actual failure was upstream: branch-local replay plus missing event state around the original Typeform submission.

That is why this stack needs to be read as one system, not three tools.

If your lane already shows duplicate Slack alerts, duplicate HubSpot writes, or confusing replay behavior, start with Make.com error handling, use HubSpot workflow automation when the lane affects sales routing, and review my operating model on About. For a published production example, see Typeform to HubSpot dedupe.

The stack people think they have

Most teams describe the lane like this:

Typeform submission
  -> HubSpot contact update
  -> Slack notification

That model is too simple to debug duplicate writes.

The stack you actually have

In production, the lane is closer to this:

Typeform submission
  -> webhook delivery
  -> Make.com trigger
  -> payload normalization
  -> processing_id creation
  -> state lookup
  -> HubSpot search
  -> HubSpot create or update
  -> Slack notification
  -> completed-state write
  -> replay / retry / error path

The duplicate can start at any step before Slack, and Slack just makes the problem visible.

The five places duplicate writes actually start

1. No stable event key from Typeform

If the lane does not treat the Typeform submission as one durable business event, every resend can look new.

Use one stable key such as:

• submission token,
• form response ID,
• or a deterministic composite key derived before any write branch.

If you skip that step, nothing downstream can reliably tell the difference between:

• same event replay,
• same event retry,
• or a new legitimate submission.

This is the same foundation described in Make.com Data Store as a state machine.

2. HubSpot create path runs before state check

This is where many duplicate contacts actually start.

The bad pattern:

1. Typeform event arrives.
2. Make.com goes straight to HubSpot create.
3. Only later does the scenario decide whether this event was already seen.

By the time you check, the duplicate side effect already happened.

The correct order is the opposite:

1. create processing_id,
2. check or write state,
3. then search or write HubSpot,
4. then notify downstream tools.

If HubSpot create runs first, Slack is only showing you a duplicate that already exists upstream.

3. Slack notification is treated as "just a message"

This is one of the biggest misconceptions in multi-tool automation.

Slack notification is often treated as harmless because it does not modify CRM state. Operationally, that is wrong.

Slack message is a business side effect when:

• it drives human follow-up,
• it creates urgency in SDR or ops channels,
• it signals a lead is ready,
• it triggers manual escalation or review.

If the same Slack side effect can happen twice for one event, your lane already has a duplicate-write problem, even if HubSpot stayed clean.

4. Success path and failure path both notify

I have seen this repeatedly in inherited Make.com scenarios:

• success branch sends Slack,
• error handler also sends Slack,
• operator replay sends Slack again,
• none of those branches check shared notification state.

That produces duplicate or triple notifications for one real submission.

The root cause is not Slack. The root cause is that notification state is local to branches instead of attached to the business event.

5. Manual replay ignores the original processing context

When operators replay a failed Typeform event manually without preserving the original processing_id, the scenario can behave like it is processing a new submission.

That can create:

• a second HubSpot create attempt,
• a second Slack notification,
• or a conflict where one part of the lane thinks the event is new and another thinks it already completed.

This is why replay must use the original event key, not a fresh execution timestamp.

For the retry side of this, see Webhook retry logic: stop duplicate CRM and finance writes.

Symptom to root cause map

Use this when the team only knows the symptom.

Symptom: duplicate Slack messages, single HubSpot write

Most likely causes:

• notification branch not keyed,
• success and error paths both notify,
• replay re-ran notification after CRM write had already completed.

Symptom: duplicate HubSpot write and duplicate Slack message

Most likely causes:

• no stable business-event key,
• state check happens after create,
• create-or-update branch is not replay-safe.

Symptom: no duplicate HubSpot record, but repeated owner alerts in Slack

Most likely causes:

• failure alert path retries with no alert dedupe,
• same failed event reprocessed multiple times,
• operator replay not marking previous alert state.

Symptom: Slack message missing even though HubSpot updated

Most likely causes:

• downstream handoff not acknowledged,
• Slack branch failed after CRM write,
• state was marked completed too early.

This is where teams need to stop asking "which app is wrong?" and start asking "which event state was missing?"

Copy-paste routing baseline

Use this as a safer baseline for the lane:

Typeform webhook
  -> normalize payload
  -> set processing_id = submission_token
  -> lookup state by processing_id
      -> completed: stop and log duplicate_prevented
      -> processing: stop and log concurrent_replay
      -> failed: route to controlled retry
      -> missing: create state=processing
  -> HubSpot search by canonical identity
  -> create_or_update contact
  -> check notification_status
      -> if not_sent: send Slack once
      -> if sent: skip Slack
  -> write state=completed + notification_status=sent
  -> on failure: write state=failed + reason_code + owner alert

That baseline matters because it forces one event state across Typeform, HubSpot, and Slack instead of letting each branch behave independently.

Minimal event contract for this stack

If the lane is important enough to alert humans, give it a small contract:

event:
  processing_id: typeform_submission_token
  source: typeform
  crm_object: contact
  crm_write_status: pending | completed | failed
  slack_notify_status: not_sent | sent | failed
  owner: revops_or_sdr_owner
  replay_mode: first_run | controlled_retry

I use a contract very close to this when hardening Typeform -> HubSpot lanes that also notify Slack. Without it, duplicate diagnosis turns into branch-by-branch guessing.

The safest ordering rule

The ordering rule is simple:

1. write or confirm event state,
2. do the critical CRM write,
3. do the human-notification side effect,
4. mark the full event as completed.

Two common mistakes break this:

• sending Slack before the CRM result is durable,
• marking event complete before Slack status is known.

Both create replay ambiguity.

Where to inspect first in Make.com

If you need to debug quickly, inspect these in order:

1. Where processing_id is created.
2. Whether every critical branch reads the same state row.
3. Whether HubSpot create/update happens before or after state gate.
4. Whether Slack send has its own sent guard.
5. Whether error handler writes failed state before notifying.

If points 3 or 4 are wrong, duplicate writes usually explain themselves within minutes.

This connects directly to HubSpot + Typeform reliability setup and HubSpot sends multiple webhooks: deduplicate in Make.com.

A 10-day hardening sequence

If the lane is already live and noisy, use this order.

Days 1-2

• map exact event path from Typeform to HubSpot to Slack,
• identify every place the same event can trigger more than once,
• confirm current event key or prove it does not exist.

Days 3-4

• add stable processing_id,
• move state gate ahead of CRM write,
• define notification status field.

Days 5-6

• harden HubSpot create-or-update branch,
• add Slack dedupe check,
• block branch-local notification logic.

Days 7-8

• test retry, replay, and partial failure paths,
• confirm that duplicate Slack alerts no longer appear for one event,
• confirm that controlled retry does not create second CRM writes.

Days 9-10

• add owner-routed failure alerts,
• sample recent runs end to end,
• hand off runbook and weekly review checks.

That is usually faster than fighting duplicates ad hoc across three tools with no shared event model. If you need the delivery path, review How it works or go straight to Contact.

One strict question before you trust the lane

Ask this:

Can we explain one Typeform submission from first webhook to final Slack message using one processing ID and one state history?

If the answer is no, the lane is not production-safe yet.

Use the free reliability checklist if you need a fast pre-flight, but do not mistake that for an actual event contract.

Bottom line

Typeform -> HubSpot -> Slack duplicate writes usually start upstream, not in Slack itself. The real causes are missing event keys, wrong Make.com branch order, replay without shared state, and notification paths that run outside the event contract.

That is why the fastest fix is not muting Slack noise. It is hardening the event path so Typeform, HubSpot, and Slack all operate on the same business state. I use this model because it removes duplicate CRM writes and duplicate human notifications at the same time.

If your lane already shows duplicate alerts, duplicate contacts, or replay confusion, start with Make.com error handling, use HubSpot workflow automation when sales operations are affected, or go straight to Contact.

FAQ

If only Slack duplicates, do we still have a duplicate-write problem?

Usually yes. If Slack is a real business side effect for human follow-up or owner routing, duplicate Slack sends are part of the same event-integrity problem even if HubSpot stayed clean.

What is the first field to add if this stack has no control layer?

Start with one stable processing_id from the original Typeform event. Without that, every retry and replay diagnosis becomes guesswork.

Should Slack send before or after HubSpot write?

Usually after the HubSpot write is confirmed and only when notification state shows it has not already been sent for that same event.

Can we fix this without rebuilding the whole scenario?

Often yes. Most lanes can be hardened by changing branch order, adding event state, and isolating replay behavior around the highest-risk writes first.

Next steps

• Book discovery call
• Ask for audit
• Service scope: Make.com error handling
• Service scope: HubSpot workflow automation
• Case proof: Typeform to HubSpot dedupe

Related reading

• HubSpot + Typeform reliability setup: prevent data loss
• HubSpot sends multiple webhooks: deduplicate in Make.com
• Webhook retry logic: stop duplicate CRM and finance writes
• Make.com Data Store as a state machine
• Run the free 12-point reliability checklist