Условный пример: бухгалтерская программа выгрузила только активных клиентов. Интеграция решила, что остальных удалили, и попыталась очистить их карточки в CRM. Фильтр сработал правильно — неверным оказался вывод о его результате.
Если программы обмениваются данными, заранее определите, что означает исчезновение записи. Это может быть архив, ограничение прав, неполная страница списка или настоящий запрос на удаление. Один ответ «не найдено» не описывает всю историю объекта.
Разделите три разных действия
Архивирование обычно означает, что запись больше не используется в текущей работе. Удаление — отдельное действие со своими последствиями. Отсутствие в выгрузке вообще может ничего не менять в исходной системе.
Зафиксируйте, какие состояния поддерживает каждая программа. Не приписывайте всем продуктам одинаковую корзину или возможность отмены. Если нужного состояния нет, согласуйте иной способ: например, запрет дальнейшего обновления после проверки ответственным.
Для компании в Казахстане сроки хранения и допустимость удаления определяют по применимым требованиям и внутренним правилам с нужным специалистом. Технический обмен не должен самостоятельно придумывать эти решения.
Откуда приходит команда
Назначьте источник решения: кто вправе отметить объект как неактуальный и должна ли эта отметка передаваться дальше. Однонаправленный обмен не обязан автоматически удалять данные в обе стороны.
Связывайте записи устойчивыми идентификаторами, а не названием компании. Название может измениться, а разные клиенты — называться похоже. Сохраните журнал: что запросили, кем подтверждено и какой результат получен.
Если выгрузка неожиданно стала маленькой или пустой, сначала проверьте фильтры, страницы, права и состояние соединения. Массовая очистка по такому результату требует остановки и разбора, а не особой исполнительности робота.
Проверьте связанные данные
Карточка может быть связана с заказами, перепиской, файлами и другими людьми. Последствия зависят от системы, сущности и используемого метода.
Например, документация удаления сделки Битрикс24 предупреждает о затрагивании связанных объектов и различии между удалением объекта и связи. Там же указан актуальный путь замены старого метода. Это причина проверять конкретную реализацию, а не копировать универсальную команду из старого примера.
До включения удаления выясните, что должно сохраниться, кто увидит результат и как обнаружить ошибочное действие. Наличие экспорта не равно проверенному восстановлению.
Испытайте на безопасных примерах
Создайте учебную пару записей и связанную с ними историю. Проверьте отдельно архивирование, удаление и отсутствие в отфильтрованной выгрузке.
Потом ограничьте права чтения и имитируйте неполный список. Интеграция не должна считать это доказательством массового удаления. Испытайте повтор события и запоздавшее обновление, чтобы не восстановить случайно уже отключённый объект.
Не проводите такой опыт на рабочих данных. Для необратимых действий заранее нужен согласованный порядок проверки и остановки.
С чего начать исправление
Если текущая CRM устраивает команду, менять её ради этого правила необязательно. Сначала опишите состояния и последствия в обеих программах, затем проверьте возможности их API — программных интерфейсов обмена.
С QQDev можно обсудить доработку REST API интеграции: принесите обезличенный пример исчезнувшей записи и ожидаемое поведение. Конкретные возможности второй системы проверяют до обещания реализации. Хорошее правило удаления начинается с понятной причины, а не с пустого списка.