Olmec Dynamics
H
·7 min read

How to Automate Google Sheets to Slack Digest Using Make.com

Automate Google Sheets to Slack digest with Make.com: batch every 10 minutes, format Slack items, and prevent duplicates using RecordID log.

Introduction

If your team is still copy-pasting spreadsheet updates into Slack, you already know the pain. Someone exports, someone else checks the same data twice, and the message either arrives late or misses a few rows. When stakeholders ask “can you send the list again, but only the new ones,” you end up doing manual reconciliation.

This is where Cross-Platform Automation (XPA) helps. In this guide, you will automate Google Sheets to Slack digest using Make.com, batching changes into a single digest message on a schedule. By the end, you will know how to wire the workflow so it posts reliably and does not duplicate items.

What You'll Need

  • Google Sheets spreadsheet with a worksheet (example: Items) that contains rows you want to notify about.
  • Slack workspace and permission to post to a channel (and a connected Slack app if your Make scenario requires it).
  • Make.com account with access to build scenarios and run scheduled tasks.
  • A basic spreadsheet schema with these recommended columns in Items:
    • RecordID (stable unique id per row)
    • UpdatedAt (timestamp that changes when the row changes)
    • Title (short human label)
    • Status (optional, used to filter digestable updates)
    • Link (optional, URL to the source)
  • Optional but strongly recommended: a second worksheet named DigestLog with:
    • RecordID
    • LastSentAt

If you want the XPA framing behind this kind of workflow, see Cross-Platform Automation (XPA).

How It Works (The Logic)

Your Make.com scenario runs on a timer, so it behaves like an operational feed, not a spam cannon.

Trigger to action logic:

  • Scheduled trigger fires every 10 minutes.
  • Make reads eligible rows from Google Sheets using UpdatedAt (and optional Status).
  • Make de-duplicates each row by checking whether RecordID exists in DigestLog.
  • Make builds one Slack message from the remaining rows.
  • Make posts that message to Slack.
  • Make writes back each included RecordID to DigestLog so the next run does not repost the same items.

That last “write-back log” step is what turns this from a demo into something your ops team can trust.

Step-by-Step Setup

1) Add stable identifiers and timestamps in Google Sheets

On your main sheet (for example Items), ensure each row has:

  • RecordID: never changes for that row.
  • UpdatedAt: changes when the row changes.

Practitioner gotcha: if RecordID is derived from row number, your digest will “forget” items when someone inserts rows.

2) Create a DigestLog worksheet for de-duplication

Create a worksheet named DigestLog with columns:

  • RecordID
  • LastSentAt

You will append to this sheet after every successful digest post.

3) Create a new Make.com scenario

In Make.com, create a Scenario and add these modules in order.

4) Add the scheduled trigger

  • Module: Scheduler (scheduled trigger)
  • Cadence: every 10 minutes
  • Timezone: set it once to match your team’s expectation

5) Compute your digest window (optional but recommended)

If your Google Sheets query supports it, define:

  • windowStart = trigger time minus 10 minutes
  • windowEnd = trigger time

If you do not want to compute it, you can still filter by UpdatedAt > last run time if you store last run timestamps. For a simple build, use the fixed window approach.

6) Read eligible rows from Items

Use a Google Sheets module like Search rows (or List rows) and filter by:

  • UpdatedAt is within the window
  • Status equals one of your digestable states (optional)

Keep the payload small. Only pull columns you will display in Slack, usually RecordID, Title, Status, UpdatedAt, and Link.

7) De-duplicate each row with DigestLog

For each eligible row:

  • Add a Google Sheets Search rows module against DigestLog
  • Filter: DigestLog.RecordID equals the row RecordID

Then:

  • If search returns a match, skip that row.
  • If no match, keep that row for the Slack digest.

Gotcha: if your sheet is large, you may need to optimize later with a cached “set” approach. For a simple build, record-by-record search is fine.

8) Build the Slack digest text

Take the remaining (deduped) rows and build:

  • Header, for example: Google Sheets digest (last 10 minutes)
  • Item count
  • A list of item lines

A good plain text template per item:

  • • {Title} | {Status} | {Link}

If you do not have Link, omit it. Keep each line short.

9) Guard: do not post empty digests

Add a filter before the Slack post:

  • Only continue if includedItemCount > 0

Otherwise you will produce a lot of boring empty messages.

10) Post to Slack

Module: Slack > Post a message

  • Channel: your target digest channel
  • Message text: the digest text you assembled

11) Write back included items to DigestLog

After the Slack post succeeds:

  • For each included RecordID, append to DigestLog:
    • RecordID
    • LastSentAt = now

This is the idempotency layer that prevents duplicates on the next schedule run.

12) Test with a staging window

  • Add 2 to 5 rows in Items with:
    • unique RecordID
    • UpdatedAt now (or within your next 10 minute window)
    • optional Status
  • Run the scenario.
  • Confirm Slack receives exactly those rows.
  • Confirm DigestLog has those RecordIDs.
  • Trigger the scenario again after the window, confirm you do not get duplicates.

Real-World Business Scenario

A small distribution business tracks shipment exceptions in Google Sheets. Dispatch updates the sheet every time a driver flags an issue, and the ops manager wants Slack updates but cannot handle one Slack post per spreadsheet edit.

With this Make.com Google Sheets to Slack digest setup:

  • Dispatch updates rows normally in Items.
  • Every 10 minutes, Make pulls only rows updated in the window.
  • Make posts one digest message to Slack.
  • Each RecordID is logged in DigestLog, so a scenario retry does not duplicate items.

The team stopped doing manual “did we include that last exception?” checks. Slack became the operational feed instead of a secondary database.

Common Variations

  1. Notify only on specific Status
  • Filter Status to only values like Blocked, Ready for Review, or Approved.
  1. Group digest items by Owner
  • If you add an Owner column, you can format the Slack message with sections per owner.
  1. Escalate critical statuses immediately
  • Add a second lightweight scenario that triggers faster for high priority Status values, while keeping this digest scenario as the batch feed.

For a deeper walkthrough that includes formatting and batching patterns, this reference is a useful companion: connect Google Sheets to Slack digest with Make.com.

What you built

You built an automated Google Sheets to Slack digest in Make.com that:

  • runs on a schedule (every 10 minutes)
  • reads eligible rows from Google Sheets
  • de-duplicates items using DigestLog keyed by RecordID
  • posts one digest message to Slack per window
  • writes sent rows back to DigestLog to prevent duplicates

Olmec Dynamics builds exactly these practical XPA workflows for teams that want reliable operational automation, not one-off scripts. If you want this tailored to your exact Google Sheets columns and Slack channel structure, see Olmec Dynamics and Cross-Platform Automation (XPA).