HubSpot и Monday.com: что ломает нативная интеграция при передаче сделок в проекты

Нативная интеграция HubSpot и Monday.com работает в одну сторону и синхронизирует кастомные поля только в момент создания элемента. Это означает: все изменения сделки после её передачи в Monday.com - сумма, стадия, ответственный, атрибуты - не попадают в проект автоматически. Менеджеры по проектам работают с данными, которые устарели в момент передачи.

Monday.com используют рядом с HubSpot как инструмент управления клиентскими проектами: продажи закрывают сделку в HubSpot, операционная команда ведёт исполнение в Monday.com. Логика выглядит разумно - пока не доходит до первого обновления данных. Тогда выясняется, что синхронизации фактически нет: есть однократный экспорт в момент создания, замаскированный под интеграцию.

Как выглядит проблема нативной интеграции HubSpot Monday.com

Компания настраивает нативную интеграцию через HubSpot Marketplace. Создаёт маппинг: поле «Сумма сделки» -> колонка «Deal Value» в Monday.com, «Ответственный менеджер» -> «Owner», «Тип клиента» -> «Client Type».

Первая сделка переходит в статус Closed Won - в Monday.com автоматически создаётся item с корректными данными. Руководитель проектной команды открывает доску и видит актуальную информацию. Система работает.

Через неделю клиент уточняет объём: сумма контракта меняется с $45 000 на $62 000. Менеджер по продажам обновляет сделку в HubSpot. В Monday.com - ничего. Item показывает $45 000.

Через месяц выясняется, что три из десяти активных проектов ведутся по устаревшим данным: изменились суммы, сменились ответственные, добавились кастомные атрибуты, которые вообще не попали в Monday.com - поле было создано уже после настройки маппинга.

Почему нативная интеграция устроена именно так

Нативная интеграция HubSpot + Monday.com - это приложение из HubSpot Marketplace, которое создаёт webhook-триггер на событие «сделка перешла в нужную стадию» и делает однократный POST-запрос к Monday.com API для создания item.

Архитектура намеренно упрощена: один trigger -> один action. Обновления не отслеживаются, потому что это потребовало бы постоянного polling или двустороннего webhook с обработкой конфликтов - задача на порядок сложнее.

Monday.com строит данные вокруг Items (элементов доски) с произвольной структурой колонок. HubSpot строит данные вокруг Deals (сделок) с жёсткой схемой свойств. Эти модели данных несовместимы без явного маппинга. Нативная интеграция решает эту проблему минимально: маппирует поля только при создании, не отслеживая дальнейшие изменения ни с одной из сторон.

Отдельная проблема - настройка маппинга требует точного совпадения названий колонок в Monday.com. Опечатка в имени колонки («Deal value» вместо «Deal Value») означает, что данные просто не попадают в поле. Никакого предупреждения нет - item создаётся, но поле остаётся пустым.

По состоянию на Q2 2026, официальная документация Monday.com прямо указывает: «Custom fields can only be synced at the time of item creation» - изменения после создания не синхронизируются.

Та же структурная проблема характерна для других нативных HubSpot-интеграций: нативная интеграция HubSpot и Jira создаёт задачи только в одном направлении и не поддерживает обновления статусов, а интеграция HubSpot и Notion теряет типы полей и работает с задержкой polling.

Что конкретно теряет бизнес

Устаревшие суммы контрактов. Изменение суммы в HubSpot не попадает в Monday.com. Проектная команда выставляет часы и планирует ресурсы по старым данным - либо переспрашивает у продаж, тратя время обеих сторон.

Потеря кастомных полей при изменении схемы. Если после первоначальной настройки в HubSpot добавили новое свойство - тип договора, регион, SLA - в нативный маппинг его нужно добавлять вручную. При этом все ранее созданные items останутся с пустым полем: автоматического backfill нет.

Дубликаты при ручных правках. Операционные менеджеры быстро понимают, что данные не обновляются, и начинают вносить изменения вручную прямо в Monday.com. Через месяц в системе сосуществуют два источника истины: HubSpot для продаж и ручные записи в Monday.com для операций. Когда они расходятся - выяснить, какие данные верные, можно только через переписку с командой.

Ограничение на один аккаунт. Нативная интеграция позволяет подключить только один HubSpot portal к одному workspace в Monday.com. Если в компании несколько команд с разными workspace - для каждой придётся настраивать отдельное решение.

Нет исторических данных. Сделки, закрытые до настройки интеграции, не переносятся автоматически. Нативная интеграция создаёт items только для новых событий. Если компания подключила интеграцию спустя полгода - весь предыдущий pipeline в Monday.com отсутствует.

Типичный результат для команды из 20+ человек: 2-3 часа в неделю на ручную сверку данных между HubSpot и Monday.com, плюс ошибки в проектном учёте, которые обнаруживаются уже после закрытия проекта.

Правильный подход: двусторонняя синхронизация через API

Рабочая интеграция HubSpot и Monday.com строится на двух компонентах: webhook на стороне HubSpot и прямом обращении к Monday.com GraphQL API.

Логика событийной модели:

1. HubSpot отправляет webhook при любом изменении сделки: смена стадии, обновление суммы, изменение кастомного поля, смена ответственного.
2. Обработчик проверяет: существует ли уже item в Monday.com для этой сделки. Если да - обновляет через change_column_value mutation. Если нет - создаёт через create_item.
3. Маппинг хранится в конфигурации и обновляется независимо от кода: добавить новое поле = одна строка в конфиге, без деплоя.

Фрагмент GraphQL-мутации для обновления item:

mutation {
  change_column_value(
    board_id: 123456789,
    item_id: 987654321,
    column_id: "deal_value",
    value: "{\"text\": \"62000\"}"
  ) {
    id
  }
}

Обратное направление - из Monday.com в HubSpot - работает аналогично: webhook на изменение статуса item обновляет стадию сделки в HubSpot через HubSpot CRM API.

Для хранения связи между сделкой HubSpot и item Monday.com удобно использовать кастомное поле в HubSpot (monday_item_id) - это позволяет мгновенно находить соответствующий item без дополнительных запросов к Monday.com API.

Такой подход решает и проблему backfill: при первом запуске обработчик проходит по всем открытым сделкам через HubSpot CRM API и создаёт соответствующие items, если они ещё не существуют.

Если вам интересна архитектура синхронизации с Monday.com GraphQL API - посмотрите на Kommo + Monday.com: автоматическое создание проектов из выигранных сделок: там та же GraphQL-модель, но на стороне другой CRM.

Кастомная интеграция этого типа занимает 2-3 недели разработки в типовом проекте Exceltic.dev. После запуска команда получает реальную двустороннюю синхронизацию без ручных сверок.

Для кого это критично

Ограничения нативной интеграции HubSpot Monday.com становятся проблемой при нескольких условиях:

• Команда из 10+ человек, где продажи и операции работают в разных инструментах
• Сделки изменяются после закрытия: корректируются суммы, добавляются условия, меняются ответственные
• В HubSpot активно используются кастомные свойства, которые должны быть видны в Monday.com
• Нужна двусторонняя синхронизация: статус проекта в Monday.com должен обновлять стадию в HubSpot

Если сделки после закрытия не меняются и в Monday.com нужно передать только базовые поля - нативная интеграция справится. Это редкий сценарий для B2B-компаний с длинным циклом исполнения.

Если вас интересует, как устроены модели данных в HubSpot и как это влияет на интеграции с внешними инструментами - сравнение моделей данных Kommo и HubSpot объясняет структурные различия между платформами.

Часто задаваемые вопросы

Можно ли настроить двустороннюю синхронизацию HubSpot Monday.com через нативную интеграцию?

Нет. По состоянию на Q2 2026, нативная интеграция работает только в одном направлении: из HubSpot в Monday.com. Обновления из Monday.com не попадают обратно в HubSpot автоматически. Для двустороннего обмена данными нужна кастомная интеграция через API обеих платформ или промежуточный сервис - Zapier, Make, Unito. Каждый из них имеет ограничения: задержки синхронизации от 10 минут до часа, стоимость от $50/мес и выше, зависимость от дополнительного инструмента в стеке.

Почему кастомные поля HubSpot не синхронизируются в Monday.com после создания item?

Это архитектурное ограничение нативного приложения. Webhook в нативной интеграции срабатывает только на событие «сделка перешла в нужную стадию» и выполняет однократный запрос на создание item. После этого механизма отслеживания изменений нет - нативная интеграция не подписывается на webhook изменений свойств сделки в HubSpot, поэтому последующие обновления она не получает.

Какие сторонние решения закрывают ограничения нативной интеграции HubSpot Monday.com?

Unito - двусторонняя синхронизация с маппингом полей, ориентирована на no-code. Make и Zapier - сценарные автоматизации, требуют настройки каждого workflow отдельно. Resynced специализируется на HubSpot + Monday.com и обновляет данные каждые 10 минут. Все они добавляют задержку и стоят дополнительно. Кастомная интеграция через API устраняет задержки и даёт полный контроль над маппингом и логикой обновлений.

Что происходит с историческими сделками HubSpot при подключении нативной интеграции?

Они не синхронизируются автоматически. Нативная интеграция создаёт items только для новых событий после момента подключения. Все сделки, закрытые раньше, нужно переносить вручную или через дополнительный скрипт. Для компаний с длинной историей - 500+ закрытых сделок - ручной перенос занимает несколько рабочих дней.

Как избежать дублирования данных, если нативная интеграция уже настроена?

Основная причина дублирования - операционные менеджеры начинают вносить данные вручную в Monday.com параллельно с тем, что приходит из HubSpot. Для предотвращения: либо чётко разграничить, какие поля редактируются только в HubSpot, а какие только в Monday.com - и поддерживать эту дисциплину организационно. Либо перейти на кастомную интеграцию с явным разграничением ответственности за каждое поле.

Итог

Нативная интеграция HubSpot и Monday.com подходит для простого сценария: передать несколько базовых полей в момент закрытия сделки и больше их не обновлять. Для команд, где данные сделки продолжают меняться после передачи в проект, нативная интеграция создаёт проблему быстро и незаметно - менеджеры начинают вносить данные вручную, возникают два источника истины, и к этому моменту исправить ситуацию без инвентаризации данных уже нельзя.

Если у вас HubSpot + Monday.com и данные между системами расходятся - опишите задачу команде Exceltic.dev. Разберём вашу схему данных и предложим архитектуру синхронизации, которая не потребует ручных сверок.