Olmec Dynamics
H
·7 min read

How to Automate an Airtable to Slack Digest Using Make.com (Advanced XPA)

Automate an Airtable to Slack digest with Make.com, with idempotency, routing, and audit logging so your daily updates stay correct.

Introduction

If you run recurring updates in Airtable and want them in Slack, the manual version gets painful fast. Someone exports a CSV, pastes summaries into Slack, and then double-checks “did we include everything?” when stakeholders ask for “the list again, but only overdue this time.”

An Airtable to Slack digest also breaks easily when you try to “just do it automatically.” Re-runs post duplicates, Slack messages get too long, and when a record changes mid-day you need deterministic rules for what gets included.

By the end, you will have an advanced Make.com build that sends a reliable Airtable to Slack digest on a schedule, with deduping, routing, and an audit trail.

One quick note: I did not find related posts to link for this exact Airtable to Slack digest topic in our internal blog database.

What You'll Need

  • Airtable
    • Base with an Items table.
    • Fields for: Title, Owner, Status, Due date, Updated timestamp (last modified or equivalent), plus digest tracking fields.
    • Ability to create and maintain filtered views (recommended).
  • Slack
    • A Slack app or bot with permission to post messages to the target channel, and access to private channels if applicable.
  • Make.com
    • A Make.com account with access to scheduled scenarios.
    • Permissions to use Slack and Airtable modules.
  • Optional but recommended
    • A dedicated Slack channel for digests to keep noise down.
    • A small “runs log” table in Airtable for auditability.

If you want the broader pattern behind Cross-Platform Automation (XPA), see Cross-Platform Automation (XPA).

How It Works (The Logic)

Your workflow follows a strict trigger to action loop:

  1. Trigger: a Make.com Scheduled trigger (example: every day at 08:00 in your timezone).
  2. Read: Make.com queries Airtable for eligible records using a pre-built view, such as “New or Updated since last digest”.
  3. Decide: Make.com applies routing logic (overdue, due soon, priority) to build counts and sections.
  4. Compose: Make.com formats a Slack message using a skimmable structure (header, counts, and grouped bullet list).
  5. Deliver: Make.com posts to Slack.
  6. Write back: Make.com updates Airtable to mark which records were included and stores a digest run id so replays do not duplicate messages.

The advanced part is idempotency. You generate a DigestRunID per scenario execution, persist it in Airtable, and use it to prevent duplicate Slack posts.

Step-by-Step Setup

This is a build that holds up in production, even with re-runs and mid-day edits.

1) Design your Airtable fields (Items table)

In your Airtable Items table, add fields like:

  • Title (single line text)
  • Owner (single select or linked record)
  • Status (single select)
  • Due date (date)
  • Updated time (use Airtable last modified or maintain your own timestamp)
  • DigestEligible (checkbox)
  • DigestStatus (single select, values like pending, sent)
  • DigestRunID (single line text)

To exclude already-sent items:

  • Your eligibility view should return items where DigestEligible = TRUE AND DigestStatus = pending AND (optional) Updated time > last run time.

2) Create Airtable views for fast queries

Create at least two filtered views:

  • View A: NewOrUpdatedSinceLastDigest
    • Filter on DigestEligible = TRUE
    • Filter on DigestStatus = pending
    • Filter on Updated time > [last digest timestamp] if you track it
  • View B: DueSoonOrOverdue (optional)
    • Filter on due logic, for example due within the next 48 hours OR overdue

Views reduce Make.com complexity and make failures easier to reason about.

3) Add a simple Airtable “Runs” table (audit logging)

Create an Airtable table called DigestRuns with fields:

  • DigestRunID (text, unique identifier)
  • Run started at (timestamp)
  • Run finished at (timestamp)
  • Items included count (number)
  • Slack message ts (text, optional)
  • Status (single select: success, failed)
  • Error details (long text)

This gives you observability when something goes wrong.

4) Build the Make.com scenario skeleton

In Make.com, create a new Scenario.

  1. Module 1: Scheduled trigger

    • Set the cadence for your digest.
    • Choose a timezone stakeholders expect.

  2. Module 2: Set variable (DigestRunID)

    • Create a unique run id, for example digest-YYYYMMDD-HHMMSS.
    • Store it in a variable named runId.

  3. Module 3: Airtable Create record in DigestRuns

    • Insert a row in DigestRuns with DigestRunID = runId and Run started at = now.

5) Retrieve eligible Airtable records

  1. Module 4: Airtable Search Records
    • Use View A: NewOrUpdatedSinceLastDigest.
    • Pull back only what you need for Slack: record id, Title, Owner, Status, Due date.

Common gotcha: if a digest can spike, cap record volume or handle paging in Make.com. Huge Slack messages fail in practice, even if modules technically succeed.

6) Route and group digest content

  1. Module 5: Router

    • Create routing rules using due date relative to now.
    • Example branches:
      • Overdue: due date < today and Status not closed
      • Due soon: due date within next 48 hours
      • Other

  2. Module 6: Aggregation

    • Build counts for each group: overdueCount, dueSoonCount, otherCount.

7) Compose a Slack message that stays readable

  1. Module 7: Build Slack message text (or blocks)
    • Recommended structure:
      • Header: Daily Digest: 2026-05-10
      • Counts line: Overdue: X, Due soon: Y, Others: Z
      • Grouped bullet lists like • [Status] Title (Owner, due YYYY-MM-DD)

Advanced tip: when record counts get large, split by Owner and send multiple messages. This is still a single XPA, just safer for readability and Slack limits.

8) Post to Slack

  1. Module 8: Slack Create message
    • Post to your digest channel.

If you can capture Slack response metadata (message timestamp), store it in DigestRuns.

9) Write back idempotency markers so re-runs do not duplicate

  1. Module 9: Airtable Update Items

    • For every Airtable record returned:
      • Set DigestStatus = sent
      • Set DigestRunID = runId

  2. Module 10: Airtable Update DigestRuns

  • Update Run finished at, Items included count, and set Status = success.

This is what turns a fragile “send a message” script into a production-grade Cross-Platform Automation (XPA).

10) Add error handling routes for production stability

  1. Module 11: Error handler
  • If Slack post fails, do not mark items as sent.
  • Update DigestRuns with Status = failed and fill in Error details.

In Make.com, use error handling routes so the scenario re-run will pick up DigestStatus = pending records.

Real-World Business Scenario

A UK logistics coordinator uses Airtable for shipment tasks. Every morning, they need a Slack digest of:

  • shipments overdue
  • shipments due in the next two days
  • anything newly assigned since yesterday

Before this, the coordinator exported rows into Slack and manually checked duplicates. After implementing the Make.com Airtable to Slack digest setup above, every scheduled run posts one clean digest. Re-runs do not duplicate messages because DigestRunID and DigestStatus enforce idempotency. Their leadership also gets consistent counts and grouped lists, so “where are the late updates?” stops being a recurring question.

Common Variations

  1. Owner-based digests

    • Group eligible records by Owner in Make.com.
    • Post one digest per owner to a dedicated channel or thread.

  2. Only notify on meaningful changes

    • Add a ChangeType field in Airtable (status changed, due date changed, new assignment).
    • Build your eligibility view to include only the change types you care about.

  3. Include a direct “View in Airtable” link

    • Add record URL to the Slack bullet line so people can jump straight to the source.

What you should verify before you go live

  • Run with a small dataset first, then simulate a re-run to confirm no duplicates.
  • Keep your Slack message structured, counts first, details second.
  • Ensure your eligibility view excludes DigestStatus = sent.

The end state you’re building

You will have an advanced Make.com scheduled workflow that reads eligible records from Airtable, builds an organized Slack digest, posts it reliably, and writes back run metadata so replays do not duplicate messages. That is the practical difference between an integration and a production-ready XPA.

If you want to wire this into your real Airtable schema and Slack channel structure, Olmec Dynamics builds XPAs like this end-to-end. Start by exploring what we do here, Cross-Platform Automation (XPA), and then connect with Olmec Dynamics.