Доработка формы на сайте Битрикс: как менять поля и уведомления без потери заявок

Доработка формы на сайте Битрикс — это изменение состава полей, правил проверки, получателей или текста уведомления в уже работающей форме. Чтобы не потерять заявки, сначала фиксируют карту формы: какие поля есть, что обязательно, куда уходит результат и кто получатель. Затем согласуют матрицу сценариев «успешная отправка / ошибка валидации / сбой отправки», выполняют изменения на стенде, проверяют регрессию и только потом выпускают на рабочий сайт с планом возврата.

Что входит в доработку формы на сайте Битрикс, а что нет

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

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

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

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

Карта формы: поля, валидация, маршрут результата, получатели

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

В карте фиксируют каждое поле: имя, тип, обязательность, источник значения, правило проверки. Отдельно описывают маршрут результата: сохраняется ли заявка в базе (например, в CRM или таблице), уходит ли письмо, передаются ли данные во внешнюю систему. Для каждого получателя указывают, кто это и зачем ему уведомление. Если получателей несколько, отмечают, кому уходит копия, а кому — основное письмо.

Валидация делится на клиентскую и серверную. Клиентская проверка удобна пользователю, но её можно обойти, поэтому серверная обязательна. В карте отмечают, какие правила уже есть: обязательность, формат email или телефона, минимальная длина, проверка на спам. Если правило задано только на клиенте, это риск: при отключённом скрипте форма может принять некорректные данные.

Маршрут результата описывают схемой: форма → обработчик → база или почта → получатель. На каждом переходе указывают, что может пойти не так. Например, письмо уходит, но попадает в спам; заявка сохраняется, но без привязки к странице; внешняя система отвечает ошибкой, а пользователь видит «спасибо». Эти сценарии попадают в матрицу проверок.

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

Как сформулировать задачу на доработку формы

Шаблон постановки задачи помогает избежать разночтений. В нём есть контекст, цель, границы, входные данные, ожидаемый результат и критерии приёмки. Контекст описывает, где находится форма и какую задачу она решает. Цель формулируется через наблюдаемый результат: например, «добавить поле “Компания” и сделать его необязательным».

Границы перечисляют, что не входит в задачу. Это защищает от расползания объёма. Входные данные — это доступы, стенд, текущая карта формы, примеры писем. Ожидаемый результат описывают так, чтобы его можно было проверить: какие поля появились, какие стали обязательными, кто получает уведомление, какой текст в письме.

Критерии приёмки — это конкретные проверки. Например: «При пустом обязательном поле форма не отправляется и показывает сообщение», «После успешной отправки письмо приходит на адрес X», «В письме есть значения всех полей». Критерии не должны быть общими: «форма работает» — не критерий. Лучше перечислить сценарии и ожидаемое поведение.

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

Варианты изменений и критерии выбора

Изменения в форме можно делать по-разному. Выбор зависит от того, насколько глубоко нужно менять логику и какие риски допустимы. Ниже — предметная таблица, которая помогает сравнить варианты по критериям.

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

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

Предметная последовательность действий

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

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

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

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

Если в проекте уже есть практика релизов, полезно свериться с материалом Релизы сайта Битрикс: как безопасно выпускать доработки. Он помогает не пропустить шаги резервирования и проверки, но не заменяет матрицу сценариев конкретной формы.

Матрица проверок: успешная отправка, ошибка валидации, сбой отправки

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

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

Ошибка валидации проверяется на каждом обязательном поле. Оставляют поле пустым, отправляют форму и убеждаются, что отправка не происходит, а пользователь видит понятное сообщение. Если поле проверяется на формат, вводят неверное значение и смотрят, что сообщение объясняет причину. Важно, чтобы после ошибки введённые данные не терялись.

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

Результаты проверок фиксируют в матрице: сценарий, ожидание, факт, статус. Если факт расходится с ожиданием, изменение не принимается. Матрица подписывается заказчиком или ответственным лицом до релиза.

Учебный пример: добавление поля и смена получателя

Учебный пример. Компания «Ромашка» (название и данные условные) использует на сайте форму обратной связи. Форма собирает имя, телефон и комментарий. Заявки уходят на общий ящик отдела продаж. Задача: добавить необязательное поле «Компания» и сделать так, чтобы заявки с заполненным полем «Компания» уходили ещё и на ящик партнёрского отдела.

Входные условия: доступ к стенду, карта формы, согласованный адрес партнёрского отдела, окно релиза. Границы: не менять другие формы, не внедрять CRM, не менять дизайн страницы. Критерии приёмки: поле «Компания» отображается, необязательно, сохраняется в заявке и попадает в письмо; при заполненном поле письмо уходит на оба адреса; при пустом — только на общий ящик; ошибки валидации по телефону работают как раньше.

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

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

Чек-лист приёмки доработки формы

• Карта формы согласована: поля, валидация, маршрут результата, получатели.
• Задача сформулирована с границами и критериями приёмки.
• Стенд подготовлен и повторяет окружение рабочего сайта настолько, насколько это возможно.
• Изменения внесены в шаблон, обработчик и настройки уведомлений.
• Успешная отправка проверена: заявка сохранена, письмо доставлено, данные корректны.
• Ошибка валидации проверена по каждому обязательному полю: отправка блокируется, сообщение понятно, данные не теряются.
• Сбой отправки смоделирован: пользователь видит сообщение, заявка не теряется безвозвратно.
• Получатели проверены: письма приходят на согласованные адреса, копии и условия работают.
• Резервная копия изменяемых файлов и настроек сделана.
• План возврата описан и проверен на стенде.
• Релиз проведён в согласованное время, после релиза выполнены контрольные проверки.
• Результаты проверок зафиксированы в матрице сценариев.

Ограничения, типичные ошибки и следующий шаг

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

Типичные ошибки: изменение только шаблона без правки обработчика; проверка только успешной отправки; отсутствие резервной копии; релиз без плана возврата; смена получателя без согласования. Ещё одна ошибка — делать изменения сразу на рабочем сайте, без стенда. Это повышает риск потери заявок и затрудняет откат.

Если форма связана с другими доработками, стоит оценить приоритет. Помочь может материал Приоритизация доработок сайта: как выбрать, что делать первым. Если задача уже сформулирована, но непонятна оценка, полезно свериться с разбором Как проверить смету доработки сайта: разбор оценки по задачам. Для комплексных изменений, выходящих за рамки одной формы, может потребоваться доработка сайтов на 1С-Битрикс.

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