Дубли заявок в n8n: как проверить фильтр перед записью в CRM

Дубли заявок заметны по двум сделкам после одной отправки формы. По внешнему виду карточек трудно понять, клиент обратился снова или система передала одну заявку дважды. Удалить одну карточку легко. Гораздо важнее найти, на каком шаге появилось второе создание, и не потерять следующее настоящее обращение.

Ниже - маршрут для владельца, который видит дубли заявок в сценарии n8n. Он подходит и для разговора с подрядчиком: вы сможете назвать поле сравнения, показать проверочный вход и попросить результат в целевой системе. Выбор платформы и полный путь обращения разобраны отдельно в статье про обработку заявок с ИИ.

Настройки сверены с официальной документацией девятого октября две тысячи двадцать шестого года. Примеры здесь учебные, с искусственными идентификаторами. Это не рассказ о ремонте клиентской CRM и не отчёт о проверке вашей версии n8n. Сначала повторите маршрут в безопасной копии; подключение рабочего потока потребует отдельной приёмки.

Где вы сейчас: откуда взялись дубли заявок

• В CRM уже две сделки, а журнала отправок нет. Попросите сохранить входные события и связь с карточками. Пока происхождение не выяснено, не включайте удаление совпадений по телефону.
• Журнал есть, в двух запусках одинаковый номер события. Перейдите к проверке ключа и настройке режима между запусками.
• Remove Duplicates уже установлен, но повтор всё равно проходит. Сверьте Operation, значение ключа и Scope, затем посмотрите историю фильтра.
• Повтор отсекается, но некоторые заявки исчезают. Проверьте сбой после фильтра и результат записи в CRM. Не очищайте историю ради повторного запуска, пока исход записи неизвестен.

Если общего учёта обращений пока нет, начните с материала про учёт заявок. Он решает другую задачу: где хранить обращение, кто за него отвечает и что считать завершением продажи. Здесь разберём один технический узел перед созданием карточки.

Что подготовить для проверки

Попросите человека, который поддерживает n8n, сделать тестовую копию и отключить в ней все внешние записи. Проверьте не только последнюю ноду CRM. Уведомление менеджеру, письмо клиенту и создание задачи тоже меняют рабочую систему. Их следует убрать из проверки фильтра или заменить безопасным просмотром результата.

Для начала достаточно подготовить:

1. Название источника, из которого приходит заявка. Если источников несколько, укажите каждый отдельно.
2. Пример входного события с номером, который остаётся тем же при повторной доставке.
3. Пример нового обращения того же условного клиента с другим номером события.
4. Ожидаемый выход каждого запуска и место, где вы увидите этот выход.

Не загружайте в нейросеть настоящую выгрузку CRM для проверки дублей заявок. Телефоны, имена, переписка и ключи доступа здесь не нужны. Искусственные метки вроде client-A позволяют проверить правило без клиентских данных. Номер события важен своей ролью, а не тем, как он выглядит в реальной заявке.

Владелец может собрать критерии и проверить результат вместе с исполнителем. Настройку доступа, проверку подписи вебхука и правила безопасной записи оставьте специалисту, который отвечает за интеграцию. Защита от дублей заявок не заменяет проверку того, кто прислал событие.

Если сценарий импортирован из каталога и ещё не работает, сначала разберите проверку шаблонов n8n. Проблемы с доступом и чужой адрес вебхука не исправляются выбором другого ключа дедупликации.

Как отличить повтор события от новой заявки

Разведите три понятия. Событие - одно обращение, которое источник отправляет в интеграцию. Попытка доставки - очередной раз, когда это событие передают получателю. Карточка CRM - результат обработки. У события может быть несколько попыток доставки, но желаемое число карточек задаётся вашим правилом обработки.

В простом сценарии «одна заявка - одна новая сделка» повтор доставки должен вести к прежнему результату. Новое обращение того же клиента должно сохраняться как новое. Для других процессов правило может отличаться: например, сообщение добавляют к существующей открытой заявке. Согласуйте это до настройки фильтра.

Таблица задаёт порядок разбора, а не встроенную функцию любой CRM. Если дубли заявок нельзя связать с событием, первым исправлением станет сохранение этой связи. Автоматическая склейка по похожему тексту не восстановит журнал, который не вели.

Есть и бизнес-граница. Один человек может сегодня спросить про ремонт, а завтра про обслуживание. Удаление второй заявки по номеру телефона сделает список дублей красивее, но обращение пропадёт. Решение о связи таких заявок относится к процессу продаж, а не к фильтру повторной доставки.

Какой ключ сравнивать, чтобы остановить дубли заявок

Попросите исполнителя показать один исходный запрос и его повтор. Сравните фактические значения поля, выбранного для фильтра. Не ограничивайтесь названием event_id: красивое имя не доказывает, что источник сохраняет значение при повторной отправке.

Хороший ключ отвечает на два вопроса. Узнаёт ли он то же событие после сбоя и перезапуска? Отличает ли он новое событие от старого? Если два независимых источника нумеруют заявки одинаково, добавьте название источника. Для нескольких видов операций может понадобиться и тип события. Состав ключа закрепляют в описании интеграции.

У Stripe в документации вебхуков прямо описано сохранение обработанных event ID. Там отдельно рассмотрен случай двух разных событий для одного изменения: для него используют ID объекта вместе с типом события. Это пример того, почему правило берут у конкретного источника, а не объявляют любое поле id универсальным ключом.

Не поручайте языковой модели определять точный технический повтор по смыслу сообщения. Для события с проверенным идентификатором достаточно обычного сравнения. Когда разбираете дубли заявок, нейросеть может помочь прочитать обезличенный журнал или составить таблицу, но решение о повторе не должно зависеть от её свободного пересказа.

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

Если в вашей связке заявки всё ещё переносятся руками или путь до CRM неясен, это задача для автоматизации бизнеса ClaudeLab. На публичной странице описан подход с одним процессом и прототипом до договора. Для обращения достаточно назвать источник, целевую CRM и наблюдаемый повтор; доступы в открытое описание не прикладывайте.

Как настроить Remove Duplicates

Официальная страница Remove Duplicates описывает разные операции одной ноды. Для дублей заявок между запусками нужен конкретный режим этой ноды.

Маршрут ниже предназначен для тестовой копии. Названия полей приведены по текущей документации. Если у вас старый вариант ноды или другой интерфейс, сначала сопоставьте его с документацией своей версии. Не выбирайте ближайший похожий пункт наугад.

1. Поставьте фильтр до внешней записи

   Найдите участок после получения и подготовки стабильного ключа, но до создания карточки, задачи или сообщения. Добавьте там Remove Duplicates. В тестовой копии вместо дальнейшего изменения рабочей системы оставьте просмотр выходных данных.

   Проверка шага: покажите весь путь от входа до фильтра. На нём не должно быть записи, которую повтор уже успеет выполнить. Если действие стоит раньше, перенос фильтра только перед CRM не защитит это действие.

2. Выберите сравнение с предыдущими исполнениями

   В поле Operation выберите Remove Items Processed in Previous Executions. Затем в Keep Items Where выберите Value Is New. По документации это условие убирает значения, которые уже встречались в прежних исполнениях.

   Проверка шага: в настройках видны именно Previous Executions и Value Is New. Remove Items Repeated Within Current Input подходит для совпадений внутри одной входной пачки. Если повтор приходит отдельным запуском, проверка одной пачки его не решает.

3. Передайте фактическое значение ключа

   В Value to Dedupe On используйте выбранное поле входного события или заранее подготовленный составной ключ. Сравниваться должно его значение из каждого входа. Проверьте, что не введена постоянная строка с названием поля и что нужное значение не пустое.

   Проверка шага: первое событие и его повтор дают одинаковый ключ; новое событие того же клиента даёт другой. Если у входа нет нужного поля, направляйте его на отдельный разбор до фильтра. Не подставляйте один общий ключ для всех заявок.

4. Выберите область истории

   В Options проверьте Scope. Node хранит данные отдельно для конкретной ноды. Workflow разделяет историю с другими Remove Duplicates, для которых в этом сценарии тоже выбран Workflow. Эти варианты описаны в документации.

   Для одной самостоятельной проверки начните с области Node и запишите этот выбор. Общую историю выбирайте только с понятным правилом для всех участвующих нод. Проверьте, не используется ли тот же ключ на другом участке, где его появление может остановить нужное действие.

5. Проверьте ёмкость истории и сохраните настройки

   В режиме Value Is New доступно History Size. Это количество элементов, которые n8n хранит для сравнения, а не часы или дни. В документации значение по умолчанию - десять тысяч ключей. Настройка относится к выбранной области истории.

   Запишите фактическое значение вместе с Scope и ключом. Оно не должно превращаться в обещание «повторы закрыты на месяц». Если бизнесу нужна защита на определённое окно повторной доставки, отдельно согласуйте хранение ключей и восстановление операций. Затем сохраните тестовую копию для проверки.

Clear Deduplication History - отдельная операция очистки сохранённых данных. Она не подтверждает успешную передачу заявки в CRM. Очистку истории рабочей ноды нельзя использовать как обычную кнопку исправления: после неё прежнее значение больше не узнаётся по удалённой истории.

Как проверить фильтр на трёх событиях

Ниже искусственный набор. dedupe_key - предложенное имя подготовленного поля, не обязательное поле n8n. client_marker помогает увидеть, что новый запрос того же клиента сохраняется. В рабочем источнике названия и путь до полей могут быть другими.

[
  {
    "source": "source-1",
    "event_id": "E-101",
    "dedupe_key": "source-1:E-101",
    "client_marker": "client-A",
    "request": "первое обращение"
  },
  {
    "source": "source-1",
    "event_id": "E-101",
    "dedupe_key": "source-1:E-101",
    "client_marker": "client-A",
    "request": "первое обращение"
  },
  {
    "source": "source-1",
    "event_id": "E-102",
    "dedupe_key": "source-1:E-102",
    "client_marker": "client-A",
    "request": "новое обращение"
  }
]

Передавайте эти элементы отдельными запусками в одном и том же тестовом сценарии. Не отправляйте весь массив одной пачкой и не объявляйте это проверкой истории между исполнениями. У каждого запуска сохраните входной ключ и выход фильтра. Проверочный маршрут не должен создавать настоящие сделки или отправлять письма.

Это ожидаемые результаты учебной проверки. Фактические результаты своей копии внесите рядом. Если входы изменились по содержанию, тест на дубли заявок не состоялся: сначала добейтесь одинаковых исходных данных.

Для новой серии используйте новые искусственные номера, чтобы не смешать её с прежней историей. Если требуется очистка именно тестовой истории, сначала убедитесь, что выбрана нужная копия и область. При области Workflow очистка затронет общую историю нескольких нод. Перед очисткой перечислите эти ноды.

Эти три запуска проверяют выбор ключа и режима. Они не проверяют параллельную доставку, потерю ответа внешнего сервиса и восстановление после перезапуска. Такую границу стоит записать рядом с результатом, иначе небольшой тест легко принять за готовность всего процесса.

Почему фильтра мало перед записью в CRM

Рассмотрите два сбоя. В первом событие прошло фильтр, а запись в CRM ещё не началась. Во втором CRM создала карточку, но ответ до n8n не дошёл. Снаружи оба запуска могут выглядеть неуспешными. Действия для них разные: в первом надо восстановить обработку, во втором сначала найти уже созданную карточку.

Именно здесь возникает риск плохого исправления. Очистить ключ и повторить всё сначала может означать второе создание. Оставить только отметку о встреченном событии может означать потерять заявку, которая не дошла до записи. Чтобы выбрать действие, нужен результат операции, а не только память фильтра.

Для рабочей интеграции попросите исполнителя описать состояния обработки. Например: принято, выполняется, завершено, требуется сверка. Названия можете выбрать свои. В состоянии «завершено» должен быть проверяемый результат - номер карточки или иной согласованный признак. Неизвестный ответ внешнего API нельзя автоматически приравнивать к отсутствию записи.

Для дублей заявок есть отдельная граница собственной и внешней базы. Когда данные хранятся в вашей базе, уникальное ограничение помогает различить одновременные попытки записи одного ключа. Документация PostgreSQL INSERT описывает обработку такого конфликта через ON CONFLICT. Это свойство записи в PostgreSQL, а не гарантия однократного создания в сторонней CRM.

Внешняя система требует своего решения. Если её API поддерживает устойчивый ключ повторной операции, проверьте условия этого механизма и используйте тот же ключ при восстановлении. Если такой защиты нет или исход неизвестен, нужен порядок сверки и отдельный разбор. Обычная цепочка «нашли по ключу - не нашли - создали» сама по себе не закрывает одновременные вызовы.

Remove Duplicates в этой схеме может быть полезным фильтром. Его документация не даёт основания объявлять всю цепочку до чужой CRM атомарной. Для владельца практический вывод простой: принимайте отдельно фильтр и отдельно запись. Общий маршрут продаж описан в статье про автоматизацию продаж; здесь важен результат именно одного входного события.

Когда отвечать на вебхук и как разбирать сбой

Stripe рекомендует быстро возвращать успешный ответ до тяжёлой логики и отдельно описывает повторную доставку. Но правило «ответить успешным кодом сразу, дальше как получится» не даёт владельцу контроля над потерянной заявкой. В критерии приёмки включите надёжное сохранение события до подтверждения и порядок дальнейшей обработки.

В вашей интеграции это может быть журнал входа или очередь с сохранением данных. Конкретный механизм выбирает исполнитель. Вы проверяете его обещанное поведение: после подтверждения событие остаётся доступным для восстановления, незавершённые операции видны, у них есть ответственный. Быстрый успешный HTTP-ответ ещё не является результатом продажи или передачи в CRM.

Для ветки повтора тоже нужна явная проверка. Отсутствие выходного элемента у фильтра не означает, что отправитель получил нужный ответ. Попросите показать, как сценарий отвечает на узнаваемый повтор и что записывает в журнал. Статусы и условия повторной доставки берите из документации вашего отправителя.

При таймауте CRM запретите слепое повторное создание до сверки. Исполнитель должен показать, где ищется прежний результат и что происходит, если его невозможно установить автоматически. Для такой заявки нужна отдельная очередь разбора. Она не должна молча исчезать из счётчиков успешно принятых событий.

На время исправления можно согласовать ручной путь обработки. Записывайте его результаты в тот же журнал. Запишите, какие события переданы человеку, какие действия он уже выполнил и как это связывается с автоматическим журналом. Иначе после включения сценария ручная и автоматическая обработка могут выполнить одну запись независимо.

Почему дубли заявок всё ещё проходят

Не меняйте все настройки сразу. Чтобы исправить дубли заявок, возьмите один подтверждённый повтор, сохраните его вход и пройдите до места второго создания. Для каждого изменения повторите ту же проверку и запишите, что стало иначе. Так вы не потеряете причину вместе с очередной «починенной» версией.

Размер истории не заменяет срок хранения. Если нужно пережить позднюю повторную отправку, сформулируйте требование через правила вашего источника. Исполнитель должен показать, где хранятся ключи в этом окне, что переживает перезапуск и как восстанавливается незавершённая запись. Универсальное число дней для всех источников здесь не подходит.

Дубли заявок, которые уже накопились в CRM, требуют отдельного решения. Настроенный фильтр будущих событий не объединяет старые сделки и не переносит переписку между ними. Не удаляйте карточки автоматически по одному совпадению контакта. Сначала подтвердите происхождение и согласуйте сохранение истории с ответственным за продажи.

Что передать подрядчику для приёмки

Карточка ниже относится к одному узлу передачи. Она не заменяет ТЗ на всю CRM. Заполните её вместе с исполнителем и сохраняйте фактические результаты рядом с ожидаемыми. Если результат пока не проверен, так и напишите, не подставляйте желаемое значение.

Участок: источник заявки - n8n - целевая CRM
Новое обращение: какое событие считается новой заявкой
Ключ: из каких проверенных полей он собран
Повтор: какие поля остаются неизменными при новой доставке
Фильтр: Operation, Keep Items Where, Value to Dedupe On
История: Scope, History Size, правила очистки
После фильтра: какие действия меняют внешние системы
Получение: где вход надёжно сохраняется до подтверждения
Результат: где записывается номер созданной карточки
Неизвестный исход: как он сверяется и кто его разбирает
Восстановление: что повторяют после разных мест сбоя
Испытание: вход - ожидаемый результат - фактический результат
Ограничения: какие случаи пока не проверены

Первый набор доказательств относится к фильтру: три отдельных входа, их ключи и выходные элементы. Второй относится к рабочей записи: одновременные попытки, сбой до внешнего действия, потеря ответа после возможного создания. Проверки внешней записи проводите только в согласованной тестовой среде; учебный JSON выше не разрешает отправлять пробные заявки реальным менеджерам.

Для неопределённого исхода заранее задайте порядок решения. Кто открывает запись в CRM? По какому внешнему номеру её ищут? Где фиксируют найденный результат? Кто разрешает новую попытку, если автоматическая сверка не дала ответа? Эти вопросы важнее обещания «дубли больше не появятся».

После включения участка проверяйте дубли заявок сверкой событий и результатов за один и тот же период. Считайте уникальные входные события, узнаваемые повторы, завершённые записи и случаи, требующие сверки. У каждого исключения должны быть причина и ответственный. Снижение числа дублей нельзя считать успехом, если одновременно исчезают новые заявки.

Чек-лист

• Одно событие, повтор доставки и новое обращение клиента различаются по записанному правилу; одинаковый телефон не является автоматическим запретом новой заявки.
• Фактический ключ стабилен у повторов и различается у новых событий; выбран Previous Executions с Value Is New.
• Scope и History Size зафиксированы; ёмкость истории не названа сроком защиты, очистка тестовой и рабочей истории разделена.
• В безопасной копии отдельно проверены первое событие, точный повтор и новое событие того же клиента; фактические выходы сохранены.
• Для рабочего потока проверены или явно отложены параллельная доставка, сбой после фильтра и неизвестный исход CRM; слепое повторное создание запрещено до сверки.
• Событие связано с результатом записи, а незавершённые случаи видны ответственному; успешный HTTP-ответ и зелёный запуск не выданы за созданную карточку.