Forem: Gwilym Pugh

Webhooks vs. Polling on monday.com: When Each Approach Actually Wins

Gwilym Pugh — Wed, 15 Apr 2026 21:08:54 +0000

Every monday.com integration I have built in the last two years has started with the same question. Do I poll the API on a schedule, or do I wire up a webhook? The honest answer is that both work, but the one you pick on day one shapes how painful the next two years of maintenance will be.

This post is the decision framework I wish someone had handed me when I was first wiring monday.com into Make.com, Zapier, and custom Node services. It covers when each approach actually wins, the specific failure modes of each, and code for the two patterns that solve 80% of real integrations.

The short version

Pick webhooks when you need near-real-time reaction to a specific event, the integration is one-way (monday to somewhere), and the target system can accept an inbound HTTP request. Pick polling when you need to aggregate across many items, the downstream system cannot receive webhooks cleanly, or you need retry logic and ordering guarantees that webhooks cannot give you.

Most teams default to whichever was easier to set up that day. That is why you end up with fragile integrations.

What webhooks actually give you

A webhook on monday.com is a subscription to a specific event on a specific board. Monday calls your endpoint with a JSON payload when something matching the event fires. The events you can subscribe to include:

create_item
change_column_value
change_status_column_value
change_specific_column_value
item_deleted
item_archived
item_moved_to_any_group
subitem_created
update_created

The minimum viable webhook is three lines of monday GraphQL:

mutation {
  create_webhook(
    board_id: 1234567890
    url: "https://yourserver.com/monday-webhook"
    event: change_status_column_value
    config: "{\"columnId\":\"status\",\"columnValue\":{\"$any$\":true}}"
  ) { id }
}

Your endpoint needs to handle two things on the first request: a challenge response, and then actual events after that.

// Express handler
app.post('/monday-webhook', (req, res) => {
  // Monday sends a challenge on webhook creation
  if (req.body.challenge) {
    return res.json({ challenge: req.body.challenge });
  }

  // Real event
  const { event } = req.body;
  const itemId = event.pulseId;
  const newStatus = event.value?.label?.text;

  // Do your thing
  processStatusChange(itemId, newStatus);
  res.sendStatus(200);
});

That is webhooks in their best light. Fast, low-latency, simple.

Where webhooks fall apart

Lost events. Monday retries a failed webhook delivery, but only a handful of times over a short window. If your server is down for an hour, events fired during that window are gone. There is no replay endpoint.
No ordering guarantee. If two column changes happen 50ms apart, they can arrive at your server out of order. For status flows where order matters, this bites.
Per-board setup. Webhooks are scoped to one board. If you have twelve boards that all need the same automation, you need twelve webhook subscriptions. A new board created tomorrow does not automatically inherit them.
Public endpoint required. Your integration needs a stable, publicly accessible URL. This rules out a lot of internal tools and makes local development annoying.
Payload is thin. The webhook body does not include the full item state. It tells you what changed, but if your handler needs the full board context, you are making an additional GraphQL call anyway.

What polling actually gives you

Polling is the opposite end of the tradeoff. You query the monday API on a schedule, diff the result against your last known state, and act on the differences. It is slower, heavier on API quota, but gives you things webhooks cannot.

The pattern that works in production:

async function pollBoard(boardId, lastCheckedAt) {
  const query = `
    query ($boardId: ID!, $cursor: String) {
      boards(ids: [$boardId]) {
        items_page(limit: 50, cursor: $cursor) {
          cursor
          items {
            id
            name
            updated_at
            column_values { id text value }
          }
        }
      }
    }
  `;

  let allItems = [];
  let cursor = null;

  do {
    const res = await mondayClient.query(query, { boardId, cursor });
    const page = res.data.boards[0].items_page;
    allItems = allItems.concat(page.items);
    cursor = page.cursor;
  } while (cursor);

  // Only act on items changed since last check
  return allItems.filter(item => item.updated_at > lastCheckedAt);
}

The key detail is updated_at. Filtering on the server side cuts quota significantly, and cursoring lets you handle boards with thousands of items without blowing the 5MB response cap.

Why polling wins more often than devs think

You cannot miss events. The full board state is authoritative on every poll. If you were down for an hour, the next poll catches up.
You can diff against custom state. Webhooks tell you what monday thinks changed. Polling lets you compare against your own historical view, which matters when you are computing derived values like velocity, drift, or SLA breaches.
Ordering is implicit. You process items in whatever order you choose. Sort by updated_at, by priority, by whatever makes sense for your downstream system.
No public endpoint needed. Polling runs from your infrastructure outward. It works from inside a VPN, from a cron job on a laptop, from a GitHub Action, from anywhere.
One job covers N boards. Your poll loop can take a list of board IDs from config. Adding a new board is a config change, not a deploy.

Where polling falls apart

Latency. You only know about changes at the next poll tick. A 5-minute interval means up to 5 minutes of delay. Some workflows do not tolerate that.
API quota. Monday enforces complexity limits. Polling 20 boards every minute with full column values will hit the cap faster than you expect.
You write the diff logic. It is not complex, but it is your responsibility. Missed state, drift between your store and monday, all on you.

The hybrid pattern that solves most real cases

This is the pattern I use on every non-trivial integration now.

Webhooks fire on events that need immediate action. A polling job runs every 15 minutes and reconciles the authoritative state. The webhook is the low-latency path for urgent events. The poll is the safety net that catches anything the webhook missed.

// Webhook handler: immediate path
app.post('/monday-webhook', async (req, res) => {
  if (req.body.challenge) return res.json({ challenge: req.body.challenge });

  await queue.enqueue({
    source: 'webhook',
    itemId: req.body.event.pulseId,
    event: req.body.event.type
  });
  res.sendStatus(200);
});

// Polling job: reconciliation path
async function reconcileBoards(boardIds, since) {
  for (const boardId of boardIds) {
    const changed = await pollBoard(boardId, since);
    for (const item of changed) {
      await queue.enqueue({
        source: 'poll',
        itemId: item.id,
        snapshot: item
      });
    }
  }
}

// Single worker dedupes by itemId, processes in order
worker.process(async (job) => {
  const { itemId } = job.data;
  const current = await fetchItem(itemId);
  await handleItem(current);
});

The queue deduplicates events from both sources on item ID. Your downstream logic runs once per real change, regardless of whether the webhook or the poll surfaced it.

This pattern survives contact with production. I have had webhook endpoints go down for half a day and lose zero events because the poll caught up. I have had polls hit quota limits and not felt latency because webhooks kept the critical path hot.

Picking the right default

If you are wiring monday.com to Make.com, Zapier, or any low-code tool: start with webhooks. The latency matters for user-facing flows, and the tools handle retries reasonably well.

If you are building a custom service, or integrating with a data warehouse, or computing anything derived from board state: start with polling. You will want the safety net, and the latency rarely matters for analytical workloads.

If you are doing anything mission-critical, or where lost events cost real money: combine both. The hybrid pattern is the only approach that does not wake you up at 3am because a webhook delivery failed during an AWS region hiccup.

The full implementation patterns for all three approaches, including retry logic, cursor management, and rate limit handling, are written up in the monday.com automation recipes guide at migratetomonday.com. Take what is useful, skip what is not.

Happy to answer questions in the comments if you are wrestling with a specific integration. Most of the real learnings come from the edge cases.

Automation Patterns That Survive Real Teams

Gwilym Pugh — Thu, 09 Apr 2026 08:13:59 +0000

About 40% of the automations I build during a monday.com implementation have stopped working correctly within 90 days of go-live.

Not because the automation engine failed. Because the business changed and nobody updated the automation. The status label got renamed. The person who owned the workflow moved teams. A new column was added and the old one became redundant. The automation kept firing, just on the wrong conditions, producing quietly broken output that nobody noticed until a report looked wrong two months later.

This isn't a monday.com problem. It's a pattern I've seen across every platform I've worked with. The automations that survive aren't the clever ones. They're the ones built with structural awareness that the business will change faster than the automation.

Here are the patterns that actually last, drawn from 50+ SMB implementations across construction, recruitment, insurance, and financial services.

1. Target the 80% case, not the edge cases

The biggest killer of automation reliability is trying to handle every possible scenario.

You build an automation to route new leads to the right sales rep based on territory. The happy path is simple: US leads go to the US team, EU leads go to the EU team. Then someone asks "what about Mexico?" So you add a rule. Then "what about contractors based in Spain but selling to Latin America?" Another rule. Then "what if the contact is from the US but the company is based in Germany?" Three more rules.

After six weeks your lead routing automation has 14 conditional branches, three of which contradict each other, and nobody can remember why rule #9 exists.

The better pattern: handle the 80% case cleanly, route the rest to a human. In monday.com terms:

When new lead created
  AND country = US
  Then assign to US Sales group

When new lead created
  AND country = UK
  OR country = Germany
  OR country = France
  Then assign to EU Sales group

When new lead created
  AND no previous rule matched
  Then assign to "Needs Review" group
  AND notify Sales Ops

The "Needs Review" bucket is where edge cases go to be handled by a human. A week in production tells you which edge cases are actually common enough to automate. The ones that happen twice in three months stay manual forever.

2. Build a manual override path for every automated decision

Every automation should have a documented way to override it.

If an automation assigns a deal owner based on territory, there should be a simple way for a sales manager to reassign it without breaking the automation's future behaviour. If an automation moves a project to "In Progress" when the client approves the proposal, there should be a way to move it back to "Pending" if the client changes their mind without the automation immediately fighting back.

The anti-pattern: an automation that instantly undoes any manual change because it sees the "wrong" state.

The fix in monday.com: use a status column for the automation's decision and a separate checkbox column (like "Locked by user") that the automation checks first. If locked, the automation skips. If unlocked, it runs.

When Status column changes
  AND Locked by user = false
  Then [automation action]

When Status column changes
  AND Locked by user = true
  Then do nothing

This small structural change is the difference between an automation the team trusts and one they work around by building a parallel spreadsheet.

3. Document trigger, action, and owner in one sentence each

Every automation needs three pieces of documentation:

Trigger: What fires this automation? (One sentence.)
Action: What does it do? (One sentence.)
Owner: Who maintains this? (A name, not a team.)

If you can't write each of these in one sentence, the automation is too complex and will break.

Keep the documentation somewhere the team can actually find it. A dedicated "Automation Registry" board in your workspace is better than a buried Confluence page. Each row is an automation. Columns are: Name, Board, Trigger, Action, Owner, Last Reviewed, Status.

Here's the schema I use:

Board: Automation Registry
Columns:
  - Name (text)
  - Parent Board (board relation)
  - Trigger Description (long text, 1 sentence)
  - Action Description (long text, 1 sentence)
  - Owner (person)
  - Last Reviewed (date)
  - Active? (checkbox)
  - Notes (long text, optional)

When something changes (new column added, new team member joined, business process updated), the team can open the registry and see which automations need reviewing. Without this, you rediscover broken automations through downstream bugs months later.

4. Weekly five-minute health check

Automations need maintenance. The teams whose automations still work a year later are the teams that review them weekly.

The review doesn't need to be complicated. Five minutes, once a week:

Open the Automation Registry board
Check which automations fired this week (monday.com shows activity logs per automation)
Check which ones failed or skipped
Scan the outputs they produced (did the notifications actually land? Did the status changes actually stick? Are the reports still correct?)

This single habit catches silent breakages before they become noisy problems. A renamed status label, a removed column, a changed field type. All of these can silently disable an automation. Weekly checks surface them before your quarterly board report shows wrong numbers.

5. Train the maintainer, not just the users

Most automation training focuses on the end users. The sales reps who benefit from lead routing. The project managers whose status updates get mirrored automatically. The ops team whose weekly reports generate themselves.

This matters, but it's not the critical training.

The critical training is for the person or people who maintain the automations after go-live. They need to understand:

How each automation works, structurally
How to diagnose when one isn't firing
How to modify it safely when the business process changes
When to remove an automation rather than patch it

Without this, any business change either breaks the system or forces the team to work around it. The person who set up the automations six months ago has long since forgotten the subtle reasons for certain design decisions, and the consultant has moved on. The result is a slow erosion of trust in the platform.

A concrete example: CRM pipeline automation

Here's a full pattern I've implemented dozens of times. This handles the end-to-end deal progression in monday.com CRM without ever hitting the "too clever" failure mode.

Boards involved:

Deals (primary)
Accounts
Projects (delivery board)
Team Capacity (resource planning)

Automations:

1. When Deal Status changes to "Won"
   AND Connected Account is not empty
   Then:
     - Move deal to "Closed - Won" group
     - Set Close Date to today
     - Create item on Projects board
     - Connect the new project to the deal
     - Notify Delivery Lead with deal context

2. When Project created from Won deal
   Then:
     - Mirror Deal Value from Deals board
     - Mirror Client Contact from Accounts board
     - Set Project Status to "Kickoff Pending"
     - Create three default subitems: Kickoff, Scope, Delivery Plan

3. When Project Status changes to "Kickoff Complete"
   Then:
     - Update connected Deal status to "Delivery Active"
     - Notify Account Manager
     - Update Team Capacity board with assigned resources

4. When Deal has been in "Proposal Sent" > 14 days
   AND Deal Status has not changed
   Then:
     - Flag deal as "Stalled"
     - Notify Deal Owner with nudge
     - Do NOT auto-send follow-up email (human decides)

Notice what this pattern does and doesn't do.

Does: Handle the predictable state transitions cleanly. Push context across boards. Alert humans when judgement is needed.

Doesn't: Auto-send outreach emails. Auto-assign deals to specific reps. Auto-adjust pricing or terms. These are human decisions that automation should prompt, not make.

The automations that survive are the ones that reduce admin, not the ones that try to replace judgement.

The principle behind all of this

Every pattern above is a specific expression of one underlying principle: build automations for how the business actually works, not how it theoretically should work.

Theoretical processes don't have exceptions. Real ones do. Theoretical users don't forget to update fields. Real ones do. Theoretical data is clean. Real data has duplicates, typos, and fields nobody has touched in 18 months.

The automations that work in production are the ones designed by someone who's seen how the business really operates, built to handle the predictable cases cleanly and route everything else to a human. The clever edge-case handling goes in version 2, after a month in production reveals which edge cases are actually common.

If you want more concrete patterns, I've collected the ones I use most often as a set of monday.com automation recipes covering lead intake, assignment routing, follow-ups, deal progression, and reporting. They're all built on the patterns above.

How to Structure a monday.com Workspace for Multi-Department Operations

Gwilym Pugh — Sun, 05 Apr 2026 14:43:00 +0000

When your company hits 30-50 people across three or more departments, your monday.com instance stops being a collection of boards and starts being an architectural decision. How you structure workspaces, boards, and permissions at this stage determines whether the platform scales with you or becomes another tool people work around.

I've set up monday.com for companies across construction, recruitment, financial services, and healthcare. The pattern is consistent: teams that think about workspace architecture early save themselves a painful restructuring 6-12 months later. Teams that don't end up with 200 boards scattered across one workspace, no naming conventions, and permissions that either lock everyone out or let everyone see everything.

Here's what I've learned about structuring workspaces for multi-department operations.

The Single-Workspace Trap

Most companies start with one workspace. Marketing has their boards, Sales has theirs, Operations has theirs. It works until it doesn't.

The breaking point usually comes from one of three places:

Permission sprawl. Your HR team has a board tracking employee reviews. It's in the same workspace as the marketing content calendar. Everyone can see both. You can set board-level permissions, but with 40 boards in one workspace, managing individual board permissions becomes a full-time job.

Information overload. When someone opens monday.com, they see every board in the workspace. A salesperson doesn't need to see the engineering sprint board. A recruiter doesn't need to see the finance reporting dashboard. But they're all there, cluttering the sidebar.

Naming collision. Marketing has a "Tasks" board. Operations has a "Tasks" board. Engineering has a "Tasks" board. Search becomes useless.

The Multi-Workspace Model

The fix is straightforward: one workspace per department or functional area. A typical structure for a 40-person company:

Company Account
├── Sales & CRM (workspace)
│   ├── Deals Pipeline
│   ├── Contacts
│   ├── Accounts
│   └── Sales Reports Dashboard
├── Operations (workspace)
│   ├── Project Delivery
│   ├── Resource Planning
│   ├── Client Onboarding
│   └── Ops Dashboard
├── Marketing (workspace)
│   ├── Content Calendar
│   ├── Campaign Tracker
│   ├── SEO Pipeline
│   └── Marketing Dashboard
├── HR & Admin (workspace)
│   ├── Recruitment Pipeline
│   ├── Employee Directory
│   ├── Leave Tracker
│   └── Onboarding Checklist
└── Company-Wide (workspace)
    ├── All-Hands Meeting Notes
    ├── OKRs / Goals
    ├── IT Requests
    └── Cross-Department Projects

Each workspace has its own membership. Sales team members are added to the Sales workspace. They can see everything in Sales, nothing in HR. If someone needs cross-department visibility (like a COO), they're added to multiple workspaces.

The Cross-Department Problem

Separate workspaces solve the permission and clutter problems. They create a new one: how do departments share data?

A sales deal that closes needs to trigger an operations onboarding workflow. A marketing campaign needs to reference the sales pipeline to calculate ROI. A new hire in HR needs to appear on the IT equipment provisioning board.

Monday.com solves this with connected boards and mirror columns. Here's how they work in practice:

Connected Boards

A board relation column lets you link items on one board to items on another board, even across workspaces. Your Deals board in the Sales workspace can have a column that connects each deal to a Project on the Operations board.

When a salesperson closes a deal, they link it to the corresponding project. Operations can now see which deal originated the project. Sales can see the project delivery status without leaving their workspace.

Mirror Columns

Once boards are connected, mirror columns let you pull specific data from the connected board into your current view. Operations doesn't need to open the Sales workspace to see the deal value or client contact. They create a mirror column that reflects that data from the Deals board.

The data stays in one place (the Deals board owns the deal value). The mirror just displays it. If Sales updates the deal value, the mirror updates automatically.

The Practical Pattern

For a typical sales-to-operations handoff:

Sales workspace has a Deals board with a "Connected Project" column (board relation to Operations > Project Delivery)
Operations workspace has Project Delivery board with mirror columns pulling Deal Value, Client Contact, and Close Date from the connected deal
An automation fires when Deal Status changes to "Won": create an item on Project Delivery, link it to the deal, notify the operations lead

The same pattern works for any cross-department workflow: marketing-to-sales lead handoff, HR-to-IT equipment provisioning, client onboarding across sales and operations.

Naming Conventions That Scale

This sounds mundane until you have 80 boards and can't find anything. Establish conventions early:

Boards: [Department] - [Purpose] or [Department] - [Entity Type]

Sales - Deals Pipeline
Ops - Project Delivery
HR - Recruitment Pipeline

Groups within boards: Use consistent status-based names

New / Incoming
In Progress / Active
Review / Approval
Done / Archived

Views: Name views by audience or purpose

"My Tasks" (filtered to current user)
"This Week" (filtered by date)
"Client: [Name]" (filtered by client)
"Manager Overview" (summary/dashboard view)

Permission Architecture

Monday.com has three permission levels that matter for workspace design:

Workspace membership:

Members can see and edit all boards in the workspace
Viewers can see but not edit

Board-level permissions:

Editable by everyone in the workspace
Editable by board owner only (others can view)
Private (only invited members)

Column-level permissions (Enterprise plan):

Restrict who can edit specific columns

The practical setup for most companies:

Role	Workspaces	Permission
Department staff	Own department + Company-Wide	Member
Department manager	Own department + any they oversee	Member
C-suite / leadership	All workspaces	Member or Viewer
External contractors	Specific boards only (via guest access)	Guest

Key principle: Default to workspace-level membership for simplicity. Only use board-level restrictions for genuinely sensitive boards (compensation data, performance reviews, legal matters).

Automations Across Workspaces

Cross-workspace automations are where the real operational value lives. The three most valuable patterns:

1. Status-triggered item creation

"When a deal moves to Won in Sales, create a project in Operations."

This eliminates the manual handoff where someone in Sales emails Operations to say "we closed the deal, can you set up the project?" The project appears automatically with all relevant deal data mirrored.

2. Date-based notifications

"When a project delivery date is 7 days away, notify the account manager in Sales."

This keeps Sales informed about delivery timelines without requiring Operations to send manual updates. The account manager can proactively reach out to the client before delivery, not after.

3. Status-based dashboard updates

"When a project status changes to Complete, update the client health score on the Accounts board."

This creates a feedback loop between delivery and relationship management. If every project is delivered on time, the account health reflects that. If projects are consistently late, Sales sees the impact on client relationships.

Common Mistakes

After setting up workspaces for dozens of companies, these are the patterns I see teams get wrong:

Too many workspaces. One team created a separate workspace for every client project. With 30 active clients, the workspace list became unmanageable. Rule of thumb: workspaces map to departments or functions, not to individual projects or clients.

Too few boards in a workspace. The opposite problem: cramming everything into three mega-boards with 50 groups each. If a board has more than 10-12 groups, it probably needs to be split into separate boards.

No Company-Wide workspace. Cross-departmental initiatives (OKRs, all-hands action items, IT requests) need a shared space. Without it, these items end up scattered across department workspaces or worse, in email.

Automations without ownership. Someone builds 30 automations connecting Sales to Operations. That person leaves. Nobody knows which automations exist or what they do. Document every automation with a name, description, and owner. Keep a simple registry board: Automation Name, Trigger, Action, Owner, Last Updated.

Getting Started

If you're restructuring an existing monday.com instance:

Audit what exists. List every board, who uses it, and which department it belongs to. You'll probably find boards nobody uses and boards that should be merged.
Design workspaces on paper first. Map departments to workspaces. Identify cross-department data flows. Decide which boards need connected columns.
Migrate one department at a time. Move their boards to a new workspace, set up permissions, and let them run for a week before moving the next department.
Build cross-workspace connections last. Get each workspace stable before adding the complexity of connected boards and automations.

For a detailed walkthrough of workspace setup including permissions and governance, I've written a workspace structure tutorial that covers the full process.

The workspace architecture you choose today will either make monday.com feel like a unified operating system for your company, or like a slightly fancier collection of spreadsheets. The difference is 2-3 days of thoughtful planning upfront.