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 |
Практический контекст для внедрения ¶
Эта страница полезна не как абстрактная справка, а как рабочая инструкция под использование ноды/паттерна «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.