How to Automate Pipedrive Deal Updates to Slack Using Make.com Webhooks

Introduction

If you run deal notifications in Slack from Pipedrive, you already know the pain. Either you poll the Pipedrive API on a schedule and still miss changes, or you fire webhooks and end up with duplicate Slack posts when retries happen. After a few weeks, sales stops trusting the channel, and the whole purpose of the integration falls apart.

This guide walks you through a reliable Cross-Platform Automation (XPA) that connects Pipedrive → Make.com → Slack using webhooks. You will build an event-driven scenario that dedupes repeats, filters for the updates you actually care about, posts a clean Slack Block Kit alert, and logs every attempt.

By the end, you will have a working pattern you can replicate across other systems.

What You'll Need

• Make.com account to build and run the scenario (paid plan recommended for production, because webhook + storage + retries often need operational headroom)
• Pipedrive account with webhook capability enabled for your account or pipeline
• Slack workspace with a Slack app that can post messages to your target channel
• A place to store dedupe keys and processing logs:
  • Make.com Data Store (preferred for simplicity) or Google Sheets (works fine but you must manage cleanup)
• A decision on your notification rules, for example:
  • only notify when stage changes into Proposal, Negotiation, or Won
  • only notify when deal value crosses a threshold

If you want the “XPA mindset” and patterns we use across integrations, start with Cross-Platform Automation (XPA).

How It Works (The Logic)

The scenario trigger is a Pipedrive webhook for a deal event such as deal.updated. Make.com receives the payload, extracts a stable dedupe key, and checks whether that key was processed recently.

If the event is new (not processed), Make.com applies your notification rules (stage/value/changed fields), formats a Slack Block Kit message, posts it to the correct channel, then writes a processing record for auditing. If anything fails, Make.com logs the failure using the same dedupe key so you can troubleshoot without spamming.

Step-by-Step Setup

1) Create a dedicated Make.com scenario for deal alerts

1. In Make.com, create a new Scenario.
2. Name it something specific, for example: Pipedrive deal.updated → Slack alerts (Webhook + Dedupe).

Why dedicated: you want one scenario to be responsible for one output (Slack deal alerts). It makes debugging and dedupe logic much easier.

2) Add the Webhook trigger

1. Add a Webhook trigger module.
2. Use the Make.com-generated webhook URL.
3. Confirm you can receive a real payload by doing a test call or using Pipedrive’s webhook test.

Gotcha: make sure you pick the correct event type in Pipedrive, because your payload shape can differ across deal.person/activity events.

3) Extract the fields you will use for routing

Immediately after the webhook trigger, add mapping/transformation steps to normalize the payload into a consistent internal schema.

Extract at minimum:

• deal_id
• event_type (for this guide: deal.created and/or deal.updated)
• stage_name (or equivalent)
• value and currency
• close_date
• owner_name or owner_id

If the payload includes IDs only (owner/person/org IDs), plan a lookup step or accept placeholders until you add enrichment.

4) Build a dedupe key that cannot collide

Duplicate Slack alerts typically come from webhook retries or multiple deliveries for the same logical change.

1. Identify a webhook identifier in the payload, commonly one of these:
   • event_id, or
   • webhook_delivery_id, or
   • a combination you can derive like deal_id + event_type + timestamp.
2. Create a single string dedupe key, for example:
   • {{deal_id}}|{{event_type}}|{{event_fingerprint}}

Gotcha: do not dedupe on deal_id alone. Every update to a deal would block subsequent notifications.

5) Add a dedupe check using storage

Pick one approach.

Option A: Make.com Data Store

1. Add a Data store lookup module using dedupe_key.
2. If the record exists, route to “Skip Slack” and finish.
3. If not found, continue to filtering and Slack.

Option B: Google Sheets

1. Create a sheet tab webhook_dedupe with columns:
   • dedupe_key
   • processed_at
   • status
2. Add a Search rows step by dedupe_key.
3. If found, skip Slack.

Gotcha: if you use Sheets, implement a cleanup routine (for example, delete records older than 30 or 45 days). Otherwise your lookups become slow.

6) Filter for meaningful deal updates

Add an If module with your notification rules.

Recommended logic for deal.updated:

• Only notify when the update is meaningful:
  • stage is in your watchlist (Proposal, Negotiation, Won)
  • OR value crosses a threshold
  • OR close date changed

If the payload includes “changed fields” you can filter using that. If it does not, you filter based on current stage and value, and you avoid noisy updates by tightening your watchlist.

Gotcha: if you notify on every deal.updated event without stage/value rules, your Slack channel becomes a background hum.

7) Create a Slack Block Kit message template

1. Add a Slack module to send a message.
2. Configure it to post using Block Kit.

A practical structure we use:

• Section: *Deal updated*: <deal title>
• Fields (2 to 4 max for readability):
  • Deal ID
  • Stage
  • Value
  • Close date
• Context: a deep link to the Pipedrive deal record

Field formatting tips:

• format close_date into a human-readable date string
• format value with thousands separators
• show currency next to the number

8) Post and then write the processing log

After the Slack post succeeds:

1. Write a record into your dedupe storage with:
   • dedupe_key
   • processed_at
   • status = success

Add an error route for failures:

• write the same dedupe_key with status = failed
• include a short error summary in a log field

Gotcha: always log failures with the dedupe key, otherwise you will keep re-posting the same failing event.

9) Test like you expect production to behave

Do a controlled test sequence:

1. Create a deal and ensure deal.created posts once.
2. Move the deal into Proposal, ensure deal.updated posts once.
3. Trigger a change that should not notify (for example, a description edit), confirm Slack does not post.
4. Force duplicate webhook delivery (if you can in a test environment) and confirm dedupe suppresses the second message.

Real-World Business Scenario

A B2B consulting firm used Pipedrive to manage proposals and Slack for end-of-day deal standups. They tried scheduled API pulls and got gaps, then switched to webhook delivery and got duplicates during lead surges. Reps started ignoring alerts because “sometimes it lies.”

After wiring Pipedrive webhooks into Make.com with a dedupe key based on the delivery fingerprint, they saw exactly one Slack Block Kit alert per meaningful stage transition. Ops also gained a processing audit trail so when something looked wrong, they could filter by deal_id and quickly determine whether it was a routing rule issue or an integration failure.

Common Variations

1. Route by pipeline owner into different Slack channels

   • Use owner_id or pipeline name to choose the target channel.

2. Thread updates per deal_id

   • Post the first message in the channel, then post follow-ups into the same thread so the deal history stays together.

3. Escalate high-value moves

   • Add a condition: if value >= X and stage becomes Negotiation or Won, also notify an internal leadership channel.

The working pattern you can reuse

You built a production-grade Cross-Platform Automation (XPA) that handles the hard parts: webhook-triggered delivery, dedupe protection to prevent duplicate Slack posts, meaningful update filtering, Block Kit message formatting, and logging for audit and troubleshooting.

If you want this tailored to your exact Pipedrive fields, Slack channels, and your stage/value rules, Olmec Dynamics builds these XPAs for teams that cannot afford messy comms. Start from Cross-Platform Automation (XPA), and we will map the scenario to your stack.