--- title: "Set/Edit Fields в n8n: нормализация данных — Nodbot" source_url: "https://nodbot.ru/nodes/set-edit-fields/" canonical_url: "https://nodbot.ru/nodes/set-edit-fields/" language: "ru" content_type: "KnowledgePage" section: "nodes" generated_at: "2026-05-30" word_count_source: 918 --- # Set/Edit Fields в n8n: нормализация данных потери полей ## AI summary Нода «Set/Edit Fields в n8n: нормализация данных потери полей» в n8n: назначение, ключевые поля, типовые ошибки, примеры workflow и проверки перед запуском. ## Best used for Страница объясняет «Set/Edit Fields в n8n: нормализация данных — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Когда нужна эта нода - Рабочий контракт данных - Нормализация phone и email - Keep Only Set: когда включать - Set/Edit Fields перед HTTP Request - Set/Edit Fields для AI Agent - Типовые ошибки - Проверка ноды на реальных items ## Source outline # Set/Edit Fields в n8n: нормализация данных потери полей Обновлено: 2026-05-29 Edit Fields, раньше Set node, — одна из самых полезных нод в n8n. Она приводит входящие данные к удобному виду: создаёт новые поля, переименовывает старые, собирает payload для API, удаляет мусор и готовит единый формат для CRM, таблицы или AI Agent. Хорошо настроенный Set/Edit Fields делает workflow понятным: после него видно, какие поля считаются «рабочим контрактом» данных. Главный риск Не включайте удаление лишних полей без причины. Частая ошибка — оставить только новые поля, а потом потерять исходный webhook payload, UTM-метки, ID заказа или служебные поля, которые понадобятся дальше. ## Когда нужна эта нода - Задача | Пример поля | Зачем - нормализовать контакт | contact_key | дедупликация CRM - подготовить payload | crm_payload | чистый JSON для HTTP Request - сохранить источник | source_system | аудит и аналитика - привести статус | normalized_status | условия IF/Switch - добавить время | received_at | разбор дублей и задержек ## Рабочий контракт данных Перед внешними API удобно собирать единый объект. Например, заявка из Tilda, VK и Telegram может приходить в разном формате, но дальше CRM должна получить один контракт: ``` { "contact_key": "79990000000", "name": "Иван Петров", "phone": "+79990000000", "email": "ivan@example.ru", "source": "tilda", "utm_source": "yandex", "received_at": "2026-05-29T09:00:00+03:00" } ``` Такой объект легче проверять, логировать и передавать в Битрикс24, amoCRM, Google Sheets или Postgres. ## Нормализация phone и email Телефон лучше приводить к стабильному виду до поиска дублей. Сырые значения +7 999 000-00-00 , 89990000000 и 7 (999) 000 00 00 должны стать одним ключом. Email приводите к нижнему регистру и убирайте пробелы. ``` {{ ($json.phone || '').replace(/\D/g, '').replace(/^8/, '7') }} {{ ($json.email || '').trim().toLowerCase() }} ``` Если телефон пустой, не делайте из него строку undefined . Лучше явно оставить пустую строку или null , а затем IF отправит такую заявку на ручную проверку. ## Keep Only Set: когда включать Опция, которая оставляет только заданные поля, полезна перед отправкой данных во внешний API: вы контролируете, что именно уйдёт наружу. Но в середине workflow она может повредить. Если позже нужна исходная строка, вложение, binary file, UTM или сырой webhook, сначала сохраните их в отдельном поле, например raw_payload . ## Set/Edit Fields перед HTTP Request Лучше не собирать большой body прямо внутри HTTP Request. Сначала создайте объект api_body в Set/Edit Fields, затем в HTTP Request передайте его как JSON. Так проще отлаживать: если API вернул 400, вы открываете вход HTTP Request и сразу видите точный body. ``` { "fields": { "TITLE": "Заявка с сайта", "NAME": "{{$json.name}}", "PHONE": [{"VALUE": "{{$json.phone}}", "VALUE_TYPE": "WORK"}], "SOURCE_ID": "WEB" } } ``` ## Set/Edit Fields для AI Agent Перед AI Agent полезно собрать отдельное поле user_prompt и отдельное поле context . Не передавайте модели весь сырой payload, если там есть токены, внутренние ID или персональные данные, которые не нужны для задачи. Чем чище вход, тем стабильнее ответ и ниже стоимость запроса. ## Типовые ошибки - Симптом | Причина | Исправление - дальше пропали поля | включили Keep Only Set | выключить или сохранить нужные поля заранее - API получает строку вместо объекта | JSON собран как текст | проверить режим выражения и тип поля - дубли в CRM не находятся | phone/email не нормализованы | создать contact_key - IF не видит статус | поле называется иначе в разных источниках | создать единое normalized_status - AI отвечает нестабильно | в модель отправляется весь сырой payload | собрать короткий prompt и нужный context ## Проверка ноды на реальных items Ноду или паттерн «Set/Edit Fields в n8n» лучше проверять не на одном item, а на наборе входов: пустой объект, массив из нескольких items, неожиданный тип поля и повтор события. Так вы увидите, где ломается mapping ещё до подключения реального API. Для этой страницы базовый источник данных: входной item по теме «Set/Edit Fields в n8n»: источник события, внешний ID, время получения и нормализованные поля. Если нода меняет внешнюю систему, добавьте dry-run или review-ветку. - Слой | Что зафиксировать | Зачем - Вход | входной item по теме «Set/Edit Fields в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Set/Edit Fields в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "source": "manual|webhook|schedule|api", "external_id": "stable-id-from-source", "received_at": "2026-05-29T10:00:00Z", "payload_version": "v1", "dry_run": true, "audit": {"workflow_id": "...", "execution_id": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Практический контекст для внедрения Эта страница полезна не как абстрактная справка, а как рабочая инструкция под использование ноды/паттерна «Set/Edit Fields в n8n: нормализация данных потери полей» в рабочем workflow, где важно понимать входные items и формат результата. Перед изменением workflow зафиксируйте источник события: входные данные по теме set edit fields: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок. Минимальная проверка перед публикацией workflow: один happy path, один пустой payload, один повтор события и одна ошибка внешнего сервиса. Для мониторинга используйте successful executions, skipped items, retry count, error branch usage; эти показатели быстро покажут, что сценарий работает иначе, чем ожидалось. ## Связанные материалы - IF, Switch и Filter — условия после нормализации. - HTTP Request — отправка подготовленного body. - Битрикс24 и n8n — payload для лидов и задач. - DaData и n8n — чистые контакты перед CRM. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.