How to connect Notion to Slack, because Notion notifications do not aggregate

Notion's notifications are per page and per mention. That is fine for a mention and useless for a question like "what changed in our documentation this week", which is the question people actually have. There is no roll-up, so the choice is between following everything and following nothing, and almost everybody ends up following nothing.

Slack is where the aggregate belongs — not as a stream of page edits, which would be worse, but as a small number of digests and a handful of routed exceptions.

What we'll cover

• The aggregation gap
• Databases, not pages
• Building it with CodeWords
• Digests that get read
• Routing by property
• The other direction: Slack into Notion
• Keeping the document authoritative
• Detecting what changed, without a change feed
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

The aggregation gap

Notion notifies per page, so following a space means following each page in it individually.

Edits are frequent and mostly trivial. Somebody fixing a typo produces the same notification as somebody rewriting a policy.

Nothing rolls up. There is no "here is what changed this week in the area you care about", which is the only form in which most people want this information.

Following everything is unusable and following nothing is the default, which is why most teams have no idea what changed in their documentation.

The integration worth building fills exactly that gap: periodic, aggregated, scoped to what a particular group cares about. Not an edit stream — that is the thing Notion already does and that people turned off.

Databases, not pages

The practical design decision, and it determines whether any of this is reliable.

Database rows have properties, which are structured and queryable. Page bodies are a block tree and are not.

Changes to a row are detectable, through the database's own last-edited property, without walking any content.

Properties support routing. A status, an owner, a team, a priority — these let you decide who should hear about a change.

Page body changes are much harder to characterise. You can tell that a page changed and not easily what changed in it, which limits what a message can usefully say.

Build on databases wherever possible, and treat page-level changes as a coarse signal for digests rather than as something to route individually.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which database, which changes matter, and who should hear about them.
3. Authorize the connection, then share the relevant pages and databases with the integration inside Notion — access is granted per page, and this manual step is why most first Notion automations find nothing.
4. Describe the exceptions: a page deleted, a property renamed, a relation pointing at nothing.
5. Test against a duplicated database and a test channel before pointing anything at the real one.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Digests that get read

One message, at a consistent time, covering a defined area. Predictability is what makes it read rather than skimmed.

Group by what changed, not by who changed it. People care about the topic, and the author is a detail.

Separate substantive from trivial. A rewritten policy and a fixed typo should not be presented identically, and the last-edited timestamp alone cannot distinguish them — a size or property-level signal can.

Name the owner where the database has one, so a reader knows who to ask.

Include what did not change but should have. Pages past their review date are more valuable in a weekly digest than pages that changed, and nothing else surfaces them.

Link directly to the page, and keep the message to a handful of lines. A digest that fills a screen is a report, and reports get postponed.

Routing by property

Where the database structure pays off.

Status transitions are the useful trigger. A row moving to "ready for review" or "approved" is an event somebody is waiting on; a row being edited is not.

Route by a team or owner property, so each group's channel gets only its own changes.

Use a priority or severity property to decide between a digest entry and an immediate message. Most things are digest material.

Handle the missing property as a case. Rows without the property your routing depends on should be reported, not silently dropped, because that is how a whole category goes unnoticed.

Do not route on free text. A status stored as text accumulates variants that differ by capitalisation, and routing on it fails in ways nobody can see.

The other direction: Slack into Notion

Frequently more valuable than the notifications, and usually built second or not at all.

Capture a decision from a thread. A message marked in some agreed way becomes a row in a decisions database, with a link back to the conversation.

Capture a request. A question that needs tracking becomes a row rather than scrolling away.

Save the thread, not a summary. The link back to the original conversation is what makes the entry useful in six months.

Confirm in the thread with a link, so the person can see it landed and stop repeating themselves.

Do not capture automatically from keywords. An automation creating rows when somebody types "decision" produces a database nobody trusts.

Keeping the document authoritative

The failure worth avoiding: the discussion moves to Slack and the document never catches up.

Post a link, not the content. A digest that includes the text of a change invites people to read it in Slack and never open the page.

Write discussion back where it matters. A conclusion reached in a thread should end up in the page as an update, and the automation can at least prompt for it.

Date the digest and keep it short-lived. The channel is a notification surface, not an archive, and Slack retention is a workspace setting unrelated to Notion's.

Point to the page as the record in the message wording. Small, and it reinforces which one is true.

Report pages that have been discussed and not updated, which is the concrete version of this problem and is detectable if you are already linking threads to pages.

Detecting what changed, without a change feed

Notion has no general change stream, so anything periodic has to work it out, and how you do that determines what the message can say.

Query by last-edited time. Databases expose it as a filterable property, which makes "what changed since the last run" a single query rather than a crawl.

Store your own cursor, the timestamp of the last successful run, durably and after processing rather than before.

Last edited does not mean meaningfully edited. A cover image change and a rewritten policy both update it, which is why a digest needs a second signal to separate substantive from trivial.

Compare property values against the previous run where the change matters — a status that moved, an owner that changed — by keeping a small snapshot of the properties you care about.

Deletions are invisible this way. An archived page stops appearing in queries rather than announcing itself, so a digest that should mention removals needs to diff against the previous snapshot.

Accept some imprecision. This is reconstruction rather than a change feed, and a digest is forgiving of that in a way an alert would not be.

Making it survive

Make it idempotent, keyed on the page and the change, so a re-run does not repeat a digest entry.

Reference properties by name carefully, since renaming a property breaks anything matching on it and people rename properties casually.

Handle pagination. Database queries are paginated and a digest built from the first page silently under-reports.

Pace requests. Notion's rate limits are modest compared with most APIs, which shapes what is practical more than anything else here.

Report the outcome. Pages checked, entries included, and anything skipped with the reason.

Limits worth knowing about

Access is per page. An integration sees only what has been explicitly shared with it, which is the most common reason an automation finds nothing.

Rate limits are modest, roughly a few requests per second, so walking a large workspace takes patience.

Block reading is recursive, so characterising a page body's change is expensive and usually not worth it.

Deleted pages are archived rather than removed, so an automation may find pages that appear gone and should check the archived flag.

Property types are strict, and writing a value of the wrong shape fails, with shapes differing per type.

What to set up first

A weekly digest for one area, from one database, with substantive changes separated from trivial ones and stale pages listed alongside. Start with a single team's area rather than the whole workspace, because a digest covering everything is a digest addressed to nobody.

Two habits make the difference. Include the pages that have not changed but are past review, since that list is more actionable than the list of what changed. And send it to the team that owns the area rather than a general channel, because the value is somebody updating a page and only owners do that.

Frequently asked questions

Why does my Notion automation see nothing?

Because access is granted per page. Sharing the relevant page or database with the integration inside Notion is a manual step, and skipping it is why nearly every first Notion automation returns empty results.

Should page edits post to Slack individually?

No. That is what Notion's own notifications do and why people turned them off. Aggregate into a digest, and route only status transitions on database rows that somebody is actually waiting on.

Why build on databases rather than pages?

Because rows have properties, which are structured, queryable, and support routing. Page bodies are block trees, which are expensive to read and hard to characterise, so a message about one cannot say much beyond "it changed".

What is the most useful thing in a weekly digest?

Pages past their review date. It is the list nothing else surfaces, it is more actionable than the list of recent changes, and in most workspaces the first run is uncomfortable reading.

Can I create Notion entries from Slack?

Yes, and it is often more valuable than the notifications. Capture decisions and requests as database rows with a link back to the thread — and trigger on an explicit action rather than on keywords, or the database fills with noise.

How do I avoid the rate limit?

Query databases with filters rather than reading everything, avoid walking block trees where properties answer the question, and pace requests. Notion's limits are lower than most APIs and they shape what is practical.

What breaks these automations?

Somebody renaming a property. Match carefully, validate that the properties you depend on still exist, and report when they do not rather than producing a silently empty digest.

How do I detect what changed without a change feed?

Query the database filtered on last-edited time, store your own cursor after each successful run, and keep a small snapshot of the properties you care about so you can say what changed rather than just that something did.

Will a digest notice deleted pages?

Not on its own. Archived pages stop appearing in queries rather than announcing themselves, so mentioning removals means diffing against the previous run's snapshot. It is worth doing — a page quietly archived is the change people most want to know about.

Related reading

• Notion and CodeWords
• Connecting Google Sheets to Notion
• CodeWords integrations and templates