Щоб передавати заявки з форми у CRM без дублювання контактів, інтеграція має знаходити наявний запис за надійним ідентифікатором, а потім оновлювати його або створювати новий. Водночас потрібно зберігати історію звернень і перевіряти, що повторна доставка тієї самої заявки не створює зайвих записів. Успішне надсилання даних саме по собі не підтверджує, що ці правила працюють.
Контакт, заявка та повторна доставка — різні речі
Контакт — запис про людину: email, телефон, ім’я та інші відомості. Заявка — конкретне звернення зі своїм змістом, часом і джерелом. Дедуплікація — зіставлення записів за визначеним ключем, щоб не створювати зайвих контактів. Оновлення знайденого контакту — наступна дія.
Наприклад, людина спочатку просить консультацію, а згодом надсилає запит на іншу послугу. Бажаний результат — один контакт і збережена історія обох звернень. Якщо інтеграція лише замінює поле «Коментар» у картці, дубля контакту немає, але попереднє звернення може зникнути. Спосіб збереження історії залежить від можливостей CRM: це може бути подання форми, активність або інший пов’язаний запис.
Окремо перевіряйте повторну доставку: інтеграційний сервіс може повторити передавання після помилки. Це не нове звернення людини. Безпечну обробку таких повторів не можна вважати стандартною властивістю будь-якого конектора — її потрібно перевірити.
Що підготувати до налаштування
- Зафіксуйте поточну схему. Запишіть, звідки надходять дані, які поля передаються та яка дія створює контакт. Перевірте, чи не працюють одночасно вбудована інтеграція і сторонній автоматизатор.
- Збережіть конфігурацію. Зробіть копію сценарію або зафіксуйте налаштування для повернення до попереднього стану.
- Підготуйте тестові записи. Використовуйте контрольовані вами адреси й позначайте дані як тестові, щоб не зачіпати реальних клієнтів.
- Перевірте доступи. Потрібен доступ до налаштувань форми, записів CRM і журналу інтеграції.
- Визначте місце збереження звернень. Переконайтеся, що нова заявка не перезаписуватиме попередню.
Якщо тест у робочій базі вже створює дублікати або знищує історію, зупиніть подальші експерименти й залучіть адміністратора CRM. Перед масовим оновленням, злиттям або видаленням контактів зробіть експорт чи резервну копію: є ризик втратити дані та зв’язки між записами.
Який спосіб інтеграції обрати
Обирайте підключення за можливістю керувати пошуком контакту, історією заявок і повторними подіями, а не лише за наявністю кнопки підключення CRM.
| Спосіб | Коли підходить | Що перевірити |
|---|---|---|
| Вбудована інтеграція | Форма підтримує вашу CRM, а стандартні правила відповідають завданню | Ключ зіставлення, правила оновлення та збереження історії |
| Сервіс автоматизації | Потрібно з’єднати сервіси без власної розробки | Пошук перед створенням, обробку неоднозначних збігів, помилок і повторів |
| Власна API-інтеграція | Потрібні спеціальні правила, журналювання та контроль помилок | Підтримку ключа, захист від паралельного створення, версію API та захист секретів |
| Ручне опрацювання або імпорт | Заявок небагато або перенесення разове | Ключ чи ID запису для зіставлення та перевірку неоднозначних збігів |
Для автоматизатора потрібен сценарій із пошуком і розгалуженням, а не лише дія «створити контакт». Вибрати інструмент допоможе порівняння Make, Zapier та n8n. Конкретні операції перевіряйте у вибраному конекторі.
Як налаштувати зіставлення й оновлення
Універсального шляху меню для всіх CRM немає. Нижче — логіка налаштування, яку потрібно реалізувати доступними засобами вашої форми, CRM або конектора.
Крок 1. Визначте ключ контакту
Для форми з email ключем може бути адреса. В інших сценаріях може знадобитися стабільний ідентифікатор користувача, якщо CRM підтримує його для пошуку або унікального запису. Ім’я саме по собі — слабкий ключ: різні люди можуть мати однакове ім’я, а одна людина — вводити його по-різному.
Якщо форма збирає лише телефон, узгодьте формат номера й перевірте точність пошуку. Схожий номер або ім’я — привід для перевірки, а не підстава автоматично об’єднати записи. За відсутності надійного ключа залишайте звернення на ручне опрацювання.
Крок 2. Перевірте зіставлення полів
Email із форми має потрапляти в поле email контакту, а текст звернення — зберігатися в історії заявки. Перевіряйте формат обов’язкових полів і випадкові пробіли на початку та наприкінці значень. Не виправляйте адресу за здогадкою.
Окремо визначте правила оновлення: чи може порожнє поле стерти відомий телефон, чи дозволено змінювати ім’я, де зберігається джерело повторного звернення. Інакше контакт залишиться один, але його дані можуть погіршитися.
Крок 3. Розділіть результати пошуку
- Збігів немає: створити контакт і зберегти його CRM ID — внутрішній ідентифікатор запису.
- Є один точний збіг: оновити дозволені поля знайденого контакту.
- Збігів кілька: передати заявку на перевірку без автоматичного вибору контакту.
- Пошук завершився помилкою: зафіксувати збій, а не запускати створення контакту.
«Не знайдено» і «не вдалося перевірити» — різні результати. Створення запису після будь-якої помилки пошуку може спричинити дублювання.
Крок 4. Збережіть історію звернення
Після визначення контакту збережіть текст заявки, джерело та час надходження доступним у CRM способом. Не використовуйте єдине поле коментаря як заміну історії, якщо кожне надсилання його перезаписує.
Якщо сповіщення має підтверджувати збереження заявки, запускайте його після успішного запису. Саме повідомлення в Telegram не доводить, що дані потрапили до CRM: це можуть бути незалежні дії сценарію.
Крок 5. Перевірте повтори та паралельні запити
Якщо сервіс передає ідентифікатор подання, використовуйте його для розпізнавання повторної доставки. Email визначає контакт, а ідентифікатор подання — конкретну заявку; вони не замінюють один одного.
Для передавання через webhook перевірте правила повторної доставки відправника. Докладніше про механіку — у статті що таке webhook і чим він відрізняється від періодичної перевірки даних. Сам спосіб доставки не гарантує захисту від дублів.
У власній API-інтеграції одного попереднього пошуку недостатньо: паралельні запити можуть не знайти контакт і одночасно створити записи. Якщо це трапляється, залучіть розробника для налаштування захисту від паралельного створення. Не повторюйте такі випробування на реальних клієнтах.
Особливості HubSpot Forms і API
Станом на 28 жовтня 2026 року документація HubSpot описує зіставлення контактів за email, але на вибір запису також можуть впливати налаштування форми та браузерні cookie.
У налаштуваннях HubSpot Forms перевірте параметр Automatically create new contacts from unknown email addresses. Якщо адреса збігається з наявним контактом, подання оновлює його. Коли параметр вимкнений, форма також може зіставляти подання за cookie. Тому інша адреса, введена в тому самому браузері, не завжди означає створення іншого контакту.
У правилах дедуплікації HubSpot описано виняток: подання з додатковою адресою контакту може замінити його основну адресу. Після тесту перевіряйте не лише кількість записів, а й основний email.
Без email зіставлення може спиратися на cookie. Якщо пристроєм користуються різні люди, їхні звернення можуть потрапити до одного контакту. Cookie не варто використовувати як універсальний спосіб усунення дублів.
Інструмент non-HubSpot forms для збирання сторонніх форм не рівнозначний серверній інтеграції. HubSpot описує обмеження для форм у iframe, деяких JavaScript-форм і односторінкових застосунків. Захоплене значення також може залишитися в поданні, але не записатися у властивість контакту через відсутність відповідного зіставлення.
Для API HubSpot описує upsert — створення або оновлення за підтримуваним унікальним ключем. Документація має датовані версії, зокрема довідник 2026-09. Маршрути /crm/v3/ залишаються в legacy-документації: перед використанням прикладу звірте версію, яку підтримує конектор.
Не вважайте довільне кастомне поле гарантовано унікальним. У changelog від 5 квітня 2023 року HubSpot застерігав, що hasUniqueValue тоді не забезпечував примусової унікальності властивостей контактів. Це історичне обмеження: поточну підтримку ключа потрібно перевіряти для конкретного об’єкта, версії API та способу запису.
Як перевірити результат і знайти причину збою
Надішліть форму з новою тестовою адресою, потім повторіть надсилання з тією самою адресою й іншим текстом. Очікуваний результат — той самий CRM ID контакту та збережена історія звернень. Далі перевірте іншу адресу в тому самому браузері, подання з іншого пристрою, некоректні значення й повторну доставку вже обробленої події.
| Не спрацювало | Можлива причина | Наступний крок |
|---|---|---|
| Подання є, але поле контакту порожнє | Поле форми не зіставлене з властивістю CRM | Порівняйте дані подання з налаштуваннями полів |
| Той самий email створює новий контакт | Немає пошуку або email записується не в те поле | Перевірте зіставлення та дію перед створенням |
| Контакт один, але попереднього звернення немає | Новий текст перезаписує поле контакту | Налаштуйте збереження історії кожної заявки |
| Інша людина змінює попередній контакт | Можливе зіставлення через cookie спільного браузера | Перевірте параметри форми та повторіть тест в іншому браузері |
| Після одного подання з’являються зайві записи | Паралельні інтеграції або повторна доставка | Зіставте журнали каналів та ідентифікатори подій |
| Після помилки з’являється дубль | Невдалий пошук трактують як відсутність контакту | Відокремте гілку помилки від створення |
Журнал інтеграції має допомагати простежити, які дані отримано, який контакт знайдено та де збережено звернення. Статус успішного виконання без перевірки фактичних записів недостатній.
Коли зупинитися й залучити фахівця
Зупиніть зміни в робочій базі, якщо зникає історія, повторні подання створюють дублікати або незрозуміло, які персональні дані передаються далі. Якщо токен API потрапив у відкритий код форми, припиніть таке використання та замініть скомпрометований секрет.
Не очищуйте наслідки масовим злиттям без перевірки адрес, телефонів, історії та пов’язаних записів. HubSpot попереджає, що злиття в інструменті керування дублікатами неможливо скасувати. Спочатку виправте механізм створення, зробіть резервну копію й перевірте зміни на тестових записах.
Збирайте лише потрібні персональні дані, обмежуйте доступ до CRM і журналів та перевіряйте умови обробки в обраних сервісах. Враховуйте Закон України «Про захист персональних даних», а якщо обробка підпадає під GDPR — також його принципи мінімізації та точності даних.
Почніть із найпростішої інтеграції, яка проходить контрольні тести: знаходить контакт за надійним ключем, контрольовано оновлює його, зберігає історію та безпечно обробляє повтори. Переходьте до складнішого сценарію або власного API лише тоді, коли стандартний інструмент не забезпечує потрібного правила. Неоднозначні збіги краще залишати на ручну перевірку, ніж автоматично приписувати заявку не тій людині.
Оновлено 28.10.2026
