Как массово обновить данные в CRM и не потерять записи при частичных ошибках

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

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

Когда массовое обновление становится отдельным процессом

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

Такую задачу нельзя сводить к команде «обновить весь список». Нужно заранее определить, какие карточки входят в операцию, что именно меняется и как команда узнает судьбу каждой строки.

Это отличается от соседних задач:

• импорт создаёт новые сущности, а здесь меняются существующие;
• предварительная проверка решает, можно ли допустить данные к записи;
• миграция переносит данные между системами;
• последующая сверка сравнивает системы, а здесь она завершает управляемое изменение.

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

Зафиксировать состав и версию изменения

До отправки подготовьте паспорт операции. Он не даёт интеграции изменить состав задания незаметно по ходу выполнения.

Связывайте строку с карточкой по неизменяемому ID CRM или другому ключу, пригодность которого подтверждена для выбранной системы. Номер строки в таблице для этого не подходит: сортировка или удаление строки изменит его.

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

Проверить возможности конкретной CRM и аккаунта

Перед разработкой отделите документированные возможности продукта от условий конкретного аккаунта.

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

Документация REST API Битрикс24 рекомендует разбивать большие операции на несколько запросов, чтобы снизить риск тайм-аута. Она также поясняет, что batch сокращает число внешних HTTP-запросов, но не отменяет ограничения ресурсоёмкости вложенных методов. Из этого нельзя вывести универсальный размер пакета или атомарность всей операции.

Для выбранного аккаунта зафиксируйте:

• метод и адрес API для чтения и изменения карточки;
• права учётной записи или приложения;
• обязательные поля и допустимые значения;
• лимиты и признаки их превышения;
• структуру успешного и ошибочного ответа;
• способ связать элемент ответа с ID карточки;
• возможность прочитать карточку после записи;
• автоматизации CRM, которые запускает изменение.

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

Разделить реестр на управляемые пакеты

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

Размер пакета и пауза между отправками зависят от API, метода, тарифа, объёма данных и текущей активности аккаунта. Универсального безопасного числа нет.

Узел HTTP Request в n8n позволяет задать количество входных элементов в пакете и интервал между пакетами. Это помогает управлять темпом запросов, но само по себе не гарантирует соблюдение лимитов CRM и не подтверждает изменение карточек. Те же требования можно реализовать без n8n — выбор инструмента следует за проверкой API и условий сопровождения.

Для каждой отправки сохраняйте номер пакета и диапазон входных записей. Если операция остановится, команда должна видеть последнюю попытку по каждой карточке, а не только название завершившегося workflow.

Вести результат по каждой исходной записи

Журнал операции связывает исходное решение, технический запрос и подтверждённое состояние CRM.

Полезный набор статусов: «не отправлено», «отправлено», «подтверждено», «отклонено», «результат неизвестен», «требует проверки сотрудником».

В n8n HTTP Request можно включить возврат заголовков и HTTP-статуса вместе с телом ответа. Однако статус запроса не заменяет правила сопоставления ответа с карточками. Даже HTTP 200 нельзя автоматически считать подтверждением всего пакета: сначала нужно разобрать формат ответа конкретного API, а при необходимости прочитать изменённые поля из CRM.

Разобрать частичную ошибку и неизвестный результат

Разделяйте три исхода:

1. CRM подтвердила изменение. Запишите подтверждённое значение и исключите карточку из повторной отправки.
2. CRM явно отклонила запись. Сохраните причину. Не повторяйте запрос, пока команда не исправит данные, права или другое постоянное условие.
3. Результат неизвестен. Соединение оборвалось или ответ нельзя однозначно связать с записью. Не приравнивайте такой исход ни к успеху, ни к отказу.

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

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

Повторять только неподтверждённые операции

Очередь повторов — требование будущего решения, а не встроенная защита любой CRM или n8n. Перед новой попыткой проверьте:

• совпадает ли ID карточки;
• осталось ли требуемое значение актуальным;
• не подтверждён ли уже результат предыдущей попытки;
• не изменил ли сотрудник карточку после подготовки реестра;
• относится ли ошибка к временным условиям.

Если повтор способен перезаписать более новое действие менеджера, автоматизация должна остановиться. Решение о приоритете изменений принимает владелец процесса, а не интеграция.

Учебный пример: замена ответственных в сделках

Ниже — синтетический пример процесса, а не клиентский кейс Switch On AI и не результат запуска в реальной CRM.

Руководитель утвердил замену ответственных в группе существующих сделок. До отправки для каждой строки подготовили ID сделки, прежнего и нового ответственного, версию данных и идентификатор операции.

Для CRM-101 журнал содержит подтверждённое значение, поэтому запись исключают из очереди повторов. CRM-102 не отправляют снова до исправления причины. У CRM-103 исход неизвестен: сначала читают карточку. Если там уже указан менеджер Б, операция завершена. Если осталось прежнее значение и повтор не конфликтует с более новой правкой, строку можно вернуть в очередь.

Этот пример показывает главное различие: технический сбой запроса не доказывает, что CRM не выполнила изменение.

Провести итоговую сверку и передать исключения

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

Итоговый отчёт разделите как минимум на группы:

• подтверждённые изменения;
• явно отклонённые записи;
• конфликты с более новыми данными;
• результаты, которые остались неизвестными;
• записи, ожидающие решения сотрудника;
• записи, исключённые по решению владельца процесса.

Для приёмки подготовьте контролируемый набор с обычным обновлением, недопустимым значением, отсутствующей или недоступной записью, частичным результатом пакета, ограничением API и неизвестным исходом запроса. Это план будущей проверки, а не заявление о выполненном тесте.

Повторный запуск считается безопасным только тогда, когда уже подтверждённые записи не изменяются заново, а судьбу каждой строки можно объяснить по журналу и фактическому состоянию CRM.

Ограничения и подготовка внедрения

Пакетная отправка не гарантирует атомарность, откат, защиту от повторов или подробный результат для каждого элемента. Возможности зависят от API, прав, редакции CRM, настроек аккаунта и внутренних автоматизаций.

Для разбора проекта подготовьте:

• обезличенный образец реестра;
• тип сущности и карту изменяемых полей;
• способ идентификации карточек;
• название и редакцию CRM;
• доступную документацию API;
• ожидаемое число записей и характер нагрузки;
• правила ручного решения конфликтов;
• критерии подтверждения результата.

Switch On AI разрабатывает интеграции, в которых маршрут данных, обработку ошибок, повторы и контроль результата согласуют до основной разработки. Для этой задачи можно обсудить один ограниченный маршрут: подготовка реестра → пакетная отправка → журнал результатов → проверка неизвестных исходов → итоговая сверка.

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