Как проверять данные перед передачей между системами

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

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

Где должна находиться проверка до записи

Проверка нужна перед первым действием, которое меняет целевую систему. Рабочий маршрут выглядит так:

1. Получить и сохранить исходное событие.
2. Нормализовать значения по явным правилам.
3. Проверить структуру и смысл данных.
4. Решить, можно ли выполнять целевую операцию.
5. Записать данные или направить событие в очередь ошибок.
6. Получить и сохранить подтверждение результата.

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

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

Как составить входной контракт записи

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

Это шаблон, а не готовый контракт для любой CRM. Конкретные поля и правила определяют по данным источника, схеме целевой сущности и последствиям ошибки.

В контракте полезно различать пять ситуаций:

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

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

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

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

Как отделить преобразование от проверки

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

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

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

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

• исходное значение;
• правило и версию карты соответствий;
• подготовленное значение;
• результат последующей проверки;
• действие при неоднозначности.

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

Какие проверки выполнить перед изменением системы

Структурные проверки отвечают на вопрос, можно ли технически обработать значение:

• присутствует ли поле;
• соответствует ли значение ожидаемому типу;
• соблюдён ли формат;
• входит ли значение в разрешённый набор.

Смысловые проверки учитывают правила процесса:

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

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

В n8n Filter node оценивает заданные условия и пропускает дальше только элементы, которые им соответствуют. Это подтверждает документация n8n, но сам узел не придумывает бизнес-правила, не доказывает полноту контроля и не создаёт очередь исправлений. Условия, сохранение отклонённых записей и запрет целевой записи нужно спроектировать и проверить отдельно.

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

Как устроить очередь ошибок и работу сотрудника

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

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

Не смешивайте разные классы проблем:

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

Для одной записи выберите режим проверки. Накопительный режим возвращает предусмотренный набор обнаруженных нарушений за один проход. Режим fail-fast останавливается на первой ошибке. Первый вариант помогает сотруднику исправить несколько полей сразу, второй может быть уместен, если дальнейшие проверки без базового значения бессмысленны. Выбранное поведение нужно явно испытать.

Как остановить недопустимую ветку и сообщить причину

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

Документация n8n указывает, что Stop And Error позволяет сформировать пользовательское сообщение или объект ошибки, завершить выполнение с ошибкой и передать собственные сведения в error workflow. Предшествующая логика должна сначала обнаружить нарушение и направить выполнение к этому узлу: Stop And Error не проверяет бизнес-условие самостоятельно.

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

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

Как вернуть исправленную запись в процесс

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

Перед повторной отправкой нужно проверить устойчивый идентификатор события и фактическое состояние целевой записи. Это снижает риск создать дубль или перезаписать более новое изменение, но конкретный механизм зависит от API и правил системы.

Разделите статусы обработки:

1. Исправлено — сотрудник изменил данные.
2. Повторно проверено — запись прошла весь контракт.
3. Отправлено — интеграция выполнила внешний запрос.
4. Подтверждено — целевая система вернула и сохранила ожидаемый результат.

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

Идемпотентность, блокировка конфликтов и правила перезаписи не следуют из описанных функций n8n. Их проектируют и тестируют для конкретных систем, версий API, прав и операций.

Условный пример: заявка из формы в CRM

Ниже — синтетическая модель процесса, а не клиентский кейс, работающий прототип или результат теста Switch On AI. Предположим, форма передаёт идентификатор обращения, имя клиента, контакт, желаемую дату связи и тему. Перед созданием карточки CRM интеграция проверяет идентификатор, наличие хотя бы одного разрешённого контакта, формат даты и соответствие темы согласованному справочнику.

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

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

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

Как принять процесс

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

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

Ограничения и данные для обсуждения внедрения

Чтобы обсудить такую автоматизацию, подготовьте:

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

Доступность API, права, тарифы и ограничения каждой системы проверяют на аудите. Автоматизация не должна обещать исправление смысла по догадке, выявление всех возможных ошибок или совместимость с любым продуктом. Решения по бухгалтерским, кадровым, юридическим и другим профессиональным данным принимает специалист заказчика. Работу с 1С Switch On AI не предлагает.

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

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