How to connect Monday.com to Slack around column values

Monday.com boards encode their meaning in columns. A status column with labels somebody chose, a people column, a date column, a formula — the board's whole process is expressed as column values, and every board expresses it differently.

That makes column changes the natural event to build on, and it makes column configuration the thing most likely to break what you build. The boards that are easiest to automate are the ones where somebody decided the column structure deliberately, and most boards are not that.

What we'll cover

• Columns are the process
• Status changes, which are the real events
• Building it with CodeWords
• Messages worth sending
• Column types that cause trouble
• Monday's own automations and integrations
• Boards, groups, and where a message belongs
• Board templates, which make all of this repeatable
• Making it survive
• Limits worth knowing about
• What to set up first
• Frequently asked questions

Columns are the process

Each board defines its own columns, with its own labels, so there is no standard shape to build against.

The same word means different things. "Done" on one board is a final state and on another is waiting for review, and nothing in the data distinguishes them.

Column identifiers are stable; titles are not. People rename column titles casually, and an automation matching on titles breaks silently.

Status labels have index values as well as text, and both can be edited, so neither is entirely safe without checking.

Groups organise items within a board, and they carry meaning too — an item moving between groups is often as significant as a status change.

Before building, read the board's column structure and write down which columns your automation depends on. That list is the contract, and validating it on each run is what turns a broken board into a clear message rather than a silent failure.

Status changes, which are the real events

A status moving to a specific label is the event worth acting on. Not any change — a particular transition that means something in that board's process.

Entering a blocked or waiting label is the highest-value one, because it is where hours matter.

Reaching the final label is what people outside the board care about.

A status moving backwards is usually worth noticing, since it means something failed review or came back.

Item creation is rarely interesting on its own, since items get created in bulk during planning.

Column value changes other than status are mostly editing, and forwarding them produces the volume problem every board integration has.

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 board, which column transitions, and who should be told.
3. Authorize the connection to Monday with an API token scoped appropriately, and to your Slack workspace.
4. Describe the exceptions: a column that no longer exists, a label that has been renamed, an item moved to another board.
5. Test against a duplicated board and a test channel before anything reaches the team.

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.

Messages worth sending

An item entered the blocked label, immediately, to the board's channel with what it is waiting on.

An item reached the final label, to whichever team was waiting — support, sales, or whoever raised it.

An item assigned, to the person in the people column, where the board uses it for real allocation rather than for interest.

A weekly board summary: what moved, what is stuck, what is overdue, and what has no owner.

Items past their date column with no recent activity, to the board owner rather than the channel.

Nothing per update, per column edit, or per subitem. Those are the noise that buries the five above.

Column types that cause trouble

Worth knowing before designing anything, because each of these produces a surprise.

Formula columns are computed and not always returned the way you expect through the API, so a message depending on one may need to compute it itself.

Mirror columns reflect another board, which means their value depends on a board your automation may not have access to.

Connect-boards columns return item identifiers, not names, so a readable message needs a second lookup.

People columns can hold several people or none, so "notify the assignee" is not always well defined.

Status labels are editable, including their text and their index, so matching on either needs validating rather than assuming.

Subitems are separate items with their own columns, and reports that ignore them silently omit a large share of the work on many boards.

Monday's own automations and integrations

Check first, because a lot of simple cases are covered.

Built-in automation recipes post to Slack on status change and similar triggers, with no development at all.

The Slack integration is maintained by Monday and handles the common notification patterns.

Automation run limits depend on plan, which is the usual reason people move logic outside.

Recipes are visible in the board to whoever manages it, which external automation never is.

Build externally when the message needs data from other systems, when you need routing logic more complex than a recipe expresses, when you are hitting run limits, or when the same logic should apply consistently across many boards rather than being configured board by board.

Boards, groups, and where a message belongs

One channel per team, not per board. Teams own several boards and a channel each multiplies until nobody is in the right ones.

Route by group where groups mean something — a board split into current and backlog groups produces very different messages from each.

Send cross-board summaries to the people who work across boards, which is usually a manager rather than the team.

Keep the automated channel separate from the team's conversation channel, or muting one mutes both.

Thread updates about the same item, so an item that changes three times is one thread rather than three messages.

Board templates, which make all of this repeatable

The difference between automating one board and automating an organisation's boards is whether the boards share a structure.

Provision boards from a template so columns, labels, and groups are identical across projects. Without that, every automation is per board and none of them transfers.

Fix the column identifiers in the template, and every board created from it inherits a structure your automation can rely on.

Agree what each status label means, once, and write it in the template's description where the next person will see it.

Report boards that deviate. Boards created before the template, or edited since, are the ones where automation silently stops working — and listing them is the only thing that surfaces it.

Carry what is already known into the new board when it is created: the customer, the dates, the scope, rather than somebody retyping.

Review the template rather than each board. One well-considered structure beats reviewing forty improvised ones, and every board created afterwards inherits the improvement.

Making it survive

Match on column identifiers, not titles, and validate that the columns you depend on still exist.

Make it idempotent, keyed on the item and the change, since webhook delivery repeats.

Handle the moved item. Items move between boards, and an automation assuming a fixed board will lose track.

Decide about subitems explicitly for every message and every report, because omitting them is the default and is usually wrong.

Report the outcome. Messages sent, transitions matched, and columns that could not be found.

Limits worth knowing about

The API is GraphQL with complexity budgets, so a deeply nested query costs more than a shallow one even as a single request.

Rate limits are enforced per account and depend on plan.

Pagination applies to item queries, and a report from the first page understates.

Webhook delivery is at-least-once, which is why idempotency matters.

Some column types are read-only or partially supported through the API, so writing back is not universally available.

What to set up first

Blocked-label notification: an item entering the blocked or waiting status, posted immediately to the board's channel with what it is waiting on and who owns it. It is the one board event where hours of delay cost something, and it is the message a team notices the absence of.

Two habits make the difference. Match on the column identifier rather than the label text, since somebody will rename the label and a title-matched automation stops silently. And include what it is waiting on from whichever column holds that, because "item blocked" prompts a question and "blocked on legal review" prompts an action.

Frequently asked questions

What Monday events are worth sending?

Specific status transitions — entering blocked, reaching done, moving backwards — plus assignment where the people column is used for real allocation. General update and column-edit events produce the volume problem every board integration has.

Why did my automation stop working?

Somebody renamed a column or a status label. Match on column identifiers, validate the columns you depend on on each run, and report clearly when one is missing rather than producing an empty result.

Should I use Monday's built-in Slack recipes?

For simple status-change notifications, yes — no building, and they stay visible in the board. Build externally for cross-board logic, for anything needing other systems, or when you are hitting automation run limits.

Why does my message show numbers instead of names?

Because connect-boards columns return item identifiers and people columns return user identifiers. Both need a second lookup to render something readable, which is worth building once rather than per message.

Do subitems appear in reports?

Only if you include them deliberately. They are separate items with their own columns, and on boards that use them heavily a report that ignores them omits most of the actual work.

One channel per board?

Per team. Teams own several boards, and a channel per board multiplies until nobody is in the right ones. Keep it separate from the team's conversation channel so muting one does not mute both.

Can automation write back to a board?

For most column types, yes, though some are read-only or only partially supported through the API. Check the specific columns you intend to write before designing around it.

How do I automate across many boards?

Provision them from a template so columns, labels, and groups match, then report the boards that deviate. Without a shared structure every automation is per board, and boards created before the template quietly stop matching it.

What should a board template fix?

Column identifiers, status labels and their meanings, and the group structure. Write what each label means in the template's description, because that is the agreement the automation depends on and it otherwise lives only in one person's head.

Is a status change always worth a message?

No — a specific transition is, and any change is not. An item moving between two working states is routine; entering a blocked label or reaching done is news. Trigger on the transition you care about rather than on the column changing.

Related reading

• Monday.com and CodeWords
• Connecting Trello to Slack
• CodeWords integrations and templates