Битрикс форма: свои поля, валидация и отправка в CRM

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

Два вида форм в 1С-Битриксе: веб-формы и CRM-формы

В модуле «Веб-формы» (Сервисы → Веб-формы → Настройка форм) живут классические веб-формы на компоненте bitrix:form. Они появились раньше CRM-модуля и умеют одно: собирать ответы в собственные таблицы результатов, показывать их в админке списком, отправлять письмо-уведомление. Дальше данные нужно куда-то деть руками или через обработчик.

Если в системе установлен модуль CRM, доступны CRM-формы на компоненте crm.form. У них другая логика: поля формы сразу привязываются к полям лида, сделки или контакта прямо в конструкторе, без единой строчки кода. Указываешь тип создаваемого элемента, сопоставляешь поля, выбираешь ответственного и источник, и заявка уже лежит в CRM в момент отправки.

На практике для нового проекта беру CRM-форму, если задача укладывается в «собрать данные и создать лид или сделку». Старые веб-формы оставляю там, где CRM не используется вообще или форма собирает что-то не для продаж: заявки на вакансию, обратную связь по браку, анкету для розыгрыша.

Свои поля формы: какие типы бывают и когда какой нужен

И у веб-форм, и у CRM-форм набор типов полей похож:

• строка - короткий ответ: имя, город, номер заказа;
• текст - многострочное поле для комментария или технического задания;
• список или флажки - выбор варианта: способ доставки, комплектация, согласие на обработку персональных данных;
• дата - желаемая дата визита или монтажа;
• файл - вложение брифа, скана документа, макета;
• телефон и email - в CRM-форме это не просто строка, а поле с привязкой к типу коммуникации CRM (WORK или MOBILE), что важно для контроля дублей;
• адрес - в CRM-форме может подтягивать подсказки при вводе, если в системе настроена соответствующая интеграция.

Часто вижу на боевых сайтах форму из трёх полей «имя, телефон, сообщение» там, где заявка потом неделю ходит по чатам, чтобы выяснить, что именно клиент хочет. Один дополнительный список («что интересует: расчёт, монтаж, гарантийный случай») на этапе формы экономит менеджеру звонок, а мне на стороне CRM-формы позволяет сразу раскидать заявки по разным направлениям через настройку в зависимости от значения поля.

Валидация: что проверяет Битрикс сам, а что добавляю руками

Обязательность поля, минимальная и максимальная длина, проверка формата email и телефона Битрикс проверяет сам, без дополнительного кода - это задаётся в параметрах поля в конструкторе формы. Там же можно указать регулярное выражение для проверки значения, и система сама сгенерирует клиентскую JS-валидацию на основе этих настроек, писать её вручную ради проверки формата не нужно.

Что берёт на себя конструктор

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

Что делаю обработчиком

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

Кросс-полевые проверки и обращения к внешним данным на уровне конструктора не собираются, это как раз тот случай, когда добавляю обработчик на PHP: он получает данные до создания элемента CRM и может остановить сохранение с текстом ошибки. Для таких сценариев беру доработку и поддержку 1С-Битрикс, от 3 000 ₽/час, если у клиента нет своего программиста под рукой.

Отправка в CRM: маппинг полей, лид или сделка

Для CRM-формы всё сводится к настройке в её конструкторе: выбираю тип создаваемого элемента (лид, сделка, контакт или связка сделка плюс контакт), сопоставляю каждое поле формы с полем CRM, задаю источник (SOURCE_ID) и ответственного. Дублей по телефону и email конструктор ищет сам через встроенный контроль дублей CRM, повторная заявка того же клиента не плодит новый лид, а попадает в существующий контакт.

Для старой веб-формы такой привязки нет, и данные нужно передать в CRM отдельно. Делаю это либо через универсальный REST-метод crm.item.add с entityTypeId 1 на обработчике, либо напрямую через API модуля CRM в обработчике события формы. Старый crm.lead.add в документации помечен DEPRECATED, развитие метода остановлено, и вендор отправляет как раз на crm.item.add. Вариант с REST удобен, если сайт и CRM физически разнесены, например форма стоит на отдельном лендинге, а CRM в облаке:

curl -X POST "https://your-domain.bitrix24.ru/rest/1/webhook_code/crm.item.add.json" \
  -H "Content-Type: application/json" \
  -d '{
    "entityTypeId": 1,
    "fields": {
      "title": "Заявка с сайта",
      "name": "Иван",
      "fm": [
        {"typeId": "PHONE", "valueType": "WORK", "value": "+79991234567"},
        {"typeId": "EMAIL", "valueType": "WORK", "value": "test@example.com"}
      ],
      "sourceId": "WEB"
    }
  }'

Если CRM стоит в том же модуле, что и сайт, проще создать лид напрямую через класс CCrmLead в обработчике:

$arFields = array(
    "TITLE" => "Заявка с сайта",
    "NAME" => $name,
    "PHONE" => array(array("VALUE" => $phone, "VALUE_TYPE" => "WORK")),
    "EMAIL" => array(array("VALUE" => $email, "VALUE_TYPE" => "WORK")),
    "SOURCE_ID" => "WEB",
    "STATUS_ID" => "NEW",
);

$lead = new CCrmLead(true);
$leadId = $lead->Add($arFields);

Оба варианта требуют обязательных полей: TITLE и хотя бы один контакт, телефон или email. Без них CRM вернёт ошибку валидации на своей стороне, это отдельный уровень проверки, независимый от валидации самой формы.

Где заявки теряются на практике

Список того, что чаще всего чиню на чужих формах уже после запуска:

• у формы не указан источник (SOURCE_ID) - заявки падают в CRM без метки и тонут среди «неразобранных», менеджер не понимает, с какой страницы пришёл клиент;
• у REST-вебхука не хватает прав на модуль CRM - вебхук создан только на чтение, а форма пытается писать, заявка не проходит, а ошибка нигде не логируется;
• контроль дублей объединяет заявки не туда - если два клиента из разных компаний используют один общий номер, например ресепшен или колл-центр, лиды слипаются в один контакт и часть истории теряется;
• форма без защиты от спама, капчи или скрытого honeypot-поля, генерирует десятки мусорных лидов в сутки, и отдел продаж перестаёт доверять уведомлениям вообще;
• при отправке формы AJAX-запросом с другого поддомена или с внешнего лендинга запрос иногда блокируется политикой браузера: пользователь не видит подтверждения, хотя лид на самом деле дошёл, и выглядит это как «форма не работает».

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

1С-Битрикс регулярно обновляется, поэтому перед внедрением я сверяюсь с актуальной документацией.

Частые вопросы

Как добавить в форму поле, которого нет в стандартном списке типов?

Стандартных типов (строка, текст, список, флажки, дата, файл, телефон, email, адрес) хватает почти всегда. Если нужен, например, слайдер диапазона цен или динамический список, зависящий от другого поля, такое собирается кастомным полем через обработчик события формы, который подменяет вёрстку конкретного вопроса, это уже программная доработка, а не настройка в админке.

Почему заявка с формы не долетает до CRM?

В большинстве случаев причина одна из трёх: не хватает прав у REST-вебхука на модуль CRM, не заполнено обязательное поле TITLE или контакт (телефон либо email) на стороне запроса, либо форма настроена как обычная веб-форма без привязки к CRM, и её результаты просто лежат в таблице модуля «Формы», никуда не отправляясь.

Можно ли одной формой создавать заявки в разные воронки в зависимости от ответа клиента?

В конструкторе CRM-формы к одной форме привязана одна воронка и один тип элемента. Чтобы разводить заявки по направлениям в зависимости от выбора в списке, обычно делаю несколько CRM-форм под разные сценарии либо добавляю обработчик, который после создания лида переносит его в нужную воронку по значению поля.

Что делать, если нужна проверка сложнее, чем регулярное выражение?

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