Olmec Dynamics
H
·7 min read

How to Automate Notion to Slack Updates Using Make.com (No Duplicate Alerts)

Automate Notion to Slack updates in Make.com: filter status transitions, route by new status, dedupe repeats, and log events in Google Sheets.

Introduction

If your team uses Notion as the project tracker, you have probably seen this pattern: a status changes, someone notices, then the update gets posted into Slack by hand. That breaks down quickly, and it usually breaks in two ways. You get duplicate alerts when multiple people post, or you get missing alerts when nobody remembers.

This is exactly the kind of work Cross-Platform Automation (XPA) is built for. In this guide, you will automate Notion to Slack updates in Make.com, only for the status transitions you care about, and with deduplication so retries do not spam your channels.

By the end, you will have a Make scenario that turns a Notion status change into a single clean Slack alert in the right channel.

What You’ll Need

  • Notion access to the database you want to monitor (and permission to read the database rows)
  • Slack access, permission to post into the target channel(s)
  • A Make.com account with connections for Notion and Slack
  • A webhook-style way to deliver Notion change events into Make (most implementations use Notion webhooks or an HTTP webhook pattern you trigger from Notion)
  • Google Sheets (recommended) to store processed dedupe keys for idempotency
  • The Notion fields you need for mapping, at minimum:
    • record/page ID
    • record title/name
    • status old value (or a way to derive it)
    • status new value
    • record URL

How It Works (The Logic)

Here is the trigger-to-action logic in plain English.

  1. Notion sends an event to Make when a database record changes.
  2. Make extracts the record ID, the previous status, the new status, and the event timestamp (or event ID).
  3. Make computes a deterministic dedupe key for that specific transition.
  4. Make checks Google Sheets to see if that dedupe key was processed already.
  5. If the transition matches your alert rules and it is not a duplicate, Make formats a Slack message.
  6. A router posts the message to the correct Slack channel based on the new status.
  7. After the Slack post succeeds, Make logs the dedupe key to Google Sheets.

The important part is step 4, the dedupe check. It is what keeps your Slack channel clean during retries and event replays.

Step-by-Step Setup

1. Define the exact status transitions that should alert Slack

In Notion, list the transitions you want. Example rules:

  • In Progress → Ready for Review
  • Blocked → In Progress
  • Ready for Review → Done

Avoid alerting on “status is now Ready for Review” without checking the previous state. That creates alerts on every unrelated edit while the record stays in that status.

2. Make sure you have status old and status new available

Your Notion change event needs both values. Depending on how your Notion events reach Make, you might have:

  • previous and current property values directly in the payload, or
  • only the current status, plus an ID you can use to fetch the previous value from another step.

If the payload only includes the new status, you will need a Notion lookup step to compare against stored state. For a clean “transition” workflow, prioritize an event payload that includes both old and new.

3. Create a Google Sheets dedupe table

Create a sheet tab named NotionSlackDedupe with columns like:

  • dedupe_key
  • processed_at
  • notion_record_id
  • status_old
  • status_new
  • slack_channel

Why a sheet? Because Make scenario memory is not durable across runs. Google Sheets gives you durable idempotency.

4. Build a new scenario in Make.com

Create a new Scenario and add modules in this order.

  1. Webhook trigger (the entry point that receives Notion change events)
  2. Tools: Set variables / parse fields
  3. Tools: Compute dedupe key
  4. Google Sheets: Search rows by dedupe_key
  5. Router / Filter (if found, stop)
  6. Filter (only continue for your allowed transitions)
  7. Router (route by status_new to the right Slack channel)
  8. Slack: Post a message
  9. Google Sheets: Add a row to store the dedupe key

5. Compute a dedupe key that is unique per transition

Use a deterministic key pattern. For example:

{{notion_record_id}}|{{status_old}}|{{status_new}}|{{event_id_or_timestamp}}

Pick event_id if your payload includes one. If you do not have an event ID, use timestamp carefully, and expect that timestamp precision matters.

6. Add the dedupe check before anything that posts to Slack

After your dedupe key is computed:

  • Google Sheets “Search rows” should look for the exact dedupe_key
  • Route:
    • If matches found: stop the scenario, no Slack post
    • If no match: continue

Gotcha: normalize strings. If your payload sometimes sends Ready for Review with different casing or whitespace, your dedupe keys will not match. Trim values early in your “Set variables” step.

7. Filter for allowed transitions

Add a filter that only continues when:

  • status_old matches one of your expected previous statuses for that transition
  • status_new matches the allowed new status

Example (logical intent):

  • continue only when (status_old == "In Progress" AND status_new == "Ready for Review") OR ...

8. Route to the correct Slack channel

Use a router based on status_new.

  • Ready for Review → #review-needed
  • Blocked → #ops-blockers
  • Done → #delivery-done

If you want higher signal, include only the fields your team needs:

  • record title
  • status old → status new
  • Notion link
  • who triggered the change (if available)

9. Post the Slack message with a consistent format

Use a consistent message template so people can scan quickly. Example:

Notion status update: {{record_title}} {{status_old}} → {{status_new}} Link: {{notion_record_url}}

10. Log the dedupe key only after Slack succeeds

After the Slack “post message” step, add:

  • Google Sheets “Add a row”

Map at minimum:

  • dedupe_key
  • processed_at
  • record ID, status old, status new, and channel

If Slack fails and Make retries, your dedupe key log prevents duplicates.

Real-World Business Scenario

A creative services team runs every client project in Notion with a single Status property. They wanted Slack alerts for two things: review is needed, and blockers need attention.

Before automation, the workflow was manual copy-paste into Slack, and the team fought channel noise. After you implement this Notion to Slack setup with Make.com, the review and blocker transitions appear once, in the right channel, even during retries. The operational win is simple: nobody has to “remember to post,” and nobody has to clean up duplicates.

Common Variations

  1. Thread replies per record Instead of posting new messages into a channel, store a mapping from notion_record_id to a Slack thread timestamp, then post updates into the same thread.

  2. Escalate by time in a status Add a second Make scenario that runs on a schedule and scans Notion for records stuck in Blocked for more than 2 days, then posts to a leadership channel.

  3. Write an “Acknowledged” property back to Notion When someone reacts to the Slack message (for example, ✅), have Make update a Notion property like Acknowledged = true so the workflow becomes feedback-driven.

Keeping your work and notifications in sync

You now have a Make.com workflow that automates Notion to Slack updates with three safeguards: strict transition filtering, routing by new status, and durable deduplication using Google Sheets.

If you want this wired to your exact Notion database schema and Slack channel layout, Olmec Dynamics builds these Cross-Platform Automation (XPA) workflows for real teams. Start from the general pattern at Cross-Platform Automation (XPA) and you can see what we do here.