Настраивайте обязательные поля HubSpot в тот момент, когда сотрудник уже может правдиво предоставить сведения, необходимые для следующего решения. Для ручного изменения этапа сделки используйте настройку соответствующего этапа, а перед развёртыванием проверьте пустые и заполненные значения. Автоматическое поступление данных нужно проверять отдельно, поскольку результат может зависеть от настроенного правила и программного маршрута передачи данных.
Сделка готова перейти дальше, но система запрашивает сведения, которых пока никто не знает. В другом случае запись доходит до следующего сотрудника с пустым полем. Сначала мы записываем, для какого решения нужна эта информация. В этом руководстве рассматриваются требования на этапах сделки; у формы на сайте и панели создания записи есть собственные настройки.
Какое правило обязательных полей HubSpot вы меняете?
Прежде чем выбирать настройку, определите, когда именно нужна информация. В руководстве HubSpot по воронкам различаются показ поля на этапе и обязательность его заполнения. Руководство по форме создания описывает требования при ручном создании записи. Эти элементы управления действуют в разные моменты: при первом вводе и при последующей передаче могут требоваться разные сведения.
Свойство - это поле записи. Воронка - последовательность этапов, по которым движется сделка. Используйте следующие различия, когда уточняете у администратора текущую конфигурацию.
| Элемент управления | На какой вопрос он отвечает |
|---|---|
| Требование формы создания | Что необходимо ввести при ручном создании записи? |
| Условное свойство этапа | Что должно отображаться или быть обязательным при ручном создании записи на этом этапе либо её перемещении на него? |
| Условная логика свойств | Какие другие поля нужно запросить, когда управляющее свойство соответствует условию? |
| Переключатель Required в форме сайта | Что посетитель обязан заполнить для отправки формы? |
| Проверка значения | Соответствует ли введённое значение поддерживаемому правилу формата или диапазона? |
HubSpot описывает их как отдельные элементы управления с разной доступностью и областью действия. Само присутствие поля на экране не означает, что оно блокирует сохранение. Даже непустое поле должно содержать осмысленный ответ.
Определите, что должен знать следующий сотрудник
Опишите предполагаемое решение обычными словами, а затем назовите информацию, которая для него нужна. Для каждого предлагаемого обязательного поля зафиксируйте, кто использует ответ, когда его можно узнать и что должно объяснять полезное значение. Если никто не может объяснить назначение поля, оставьте требование на рассмотрении.
Например, перед подготовкой предложения сотруднику может понадобиться ясное описание запроса потенциального клиента. Согласуйте, что должно содержать это описание. Если раньше времени потребовать предположительный ответ, решение останется нерешённым, даже если в поле появится текст.
Предусмотрите явный порядок работы с пока неизвестной информацией. Попросите ответственного сотрудника пересмотреть этап или момент применения требования. Перед изменением правила сохраните существующие данные и проверьте зависимости; удаление полей и добавление фиктивных значений не входят в эту процедуру.
Если из-за конфликтующих записей непонятно, чьи данные вы меняете, сначала решите вопрос идентификации. В отдельном руководстве по проверке дубликатов контактов HubSpot объясняется, почему объединение требует собственных проверок.
Настройте поле для нужного этапа сделки
Следуйте описанной HubSpot процедуре настройки этапа вместе с действующим уполномоченным администратором. Согласно руководству по воронкам, нужны разрешение Edit property settings и существующее редактируемое зависимое свойство. Перед началом проверьте подписку и доступность объекта в конкретном аккаунте; отсутствие элемента управления - повод обратиться к администратору, а не покупать более дорогой тариф на основании предположения.
До любых изменений зафиксируйте прежнее правило и согласуйте способ его восстановления. Подготовьте разрешённые тестовые записи в среде, где проверки не смогут связаться с клиентами, запустить кампании или выставление счетов либо изменить рабочую отчётность. Если такой изоляции нет, попросите администратора подготовить её до тестирования.
- Откройте Settings, затем Data Management и Objects. Выберите нужный объект и вкладку Pipelines.
- Выберите нужную воронку. В строке целевого этапа откройте Add rule в разделе Conditional logic rules.
- Подтвердите условие этапа и добавьте зависимое свойство. Выберите Required, если отсутствие значения должно блокировать охватываемое правилом ручное действие.
- Нажмите Save logic и точно запишите, к какому этапу и свойству относится правило.
Согласно тому же руководству, свойства только для чтения, включая вычисляемые значения и показатели оценки, нельзя использовать как свойства этапа. Если поле недоступно, проверьте его определение, прежде чем создавать другое поле с тем же назначением.
До развёртывания проверьте пустые и заполненные значения
Проверьте согласованное условие на разрешённой синтетической записи и до выполнения действия зафиксируйте ожидаемый результат. Сначала оставьте выбранное поле пустым, затем укажите осмысленное тестовое значение. После повторного открытия записи проверьте сохранённые этап и поле. Результат относится только к фактически проверенным условию, человеку или системе и маршруту.
- Попробуйте выполнить охватываемое правилом ручное изменение этапа при пустом зависимом значении. Запишите, препятствует ли соответствующий запрос сохранению; неожиданный результат остаётся открытым вопросом.
- Укажите явно вымышленное тестовое значение, которое всё же соответствует согласованному смыслу. Повторите действие и проверьте, что сохранилось.
- Отдельно проверьте этап вне настроенного условия, чтобы выявить неожиданно широкое действие требования.
- Храните вместе исходное состояние, ожидаемый и наблюдаемый результаты, а также имя ответственного за устранение расхождения.
Осторожно используйте одну и ту же запись, чтобы ранее сохранённое значение не сделало последующую проверку пустого поля недействительной. Попросите администратора подготовить нужное исходное состояние. Успешного действия на экране недостаточно для подтверждения сохранённого результата.
Проверьте маршруты, которые записывают данные
Успешная ручная проверка не показывает, как требование обрабатывают рабочий процесс, импорт, форма сайта или коннектор. Рабочий процесс - это автоматизированный процесс внутри HubSpot; API - программный интерфейс, через который коннектор может записывать данные. В руководстве HubSpot по условным свойствам изменения через рабочие процессы не входят в описанную область ручных действий.
В журнале изменений для разработчиков описано применение настроенных условно обязательных свойств и требований при создании записей в версии API 2026-09, причём требования создания применяются к запросам POST. Поэтому имеют значение фактический маршрут и версия коннектора.
Попросите специалиста, отвечающего за каждый используемый маршрут, определить правило и провести разрешённые проверки с отсутствующими и полными входными данными. Не нужно добавлять импорт или интеграцию только ради тестирования. Храните отдельный результат для каждого существующего маршрута, включая возвращённое сообщение, сохранённый этап и значение, если их можно проверить.
Журнал изменений API не рекомендует повторять тот же отклонённый запрос без изменений. Если запись отклонена, сохраните обращение в рамках утверждённого процесса и назначьте видимого ответственного за исправление. Перед повторной проверкой исследуйте отсутствующие данные или сопоставление; не ослабляйте правило только ради успешного запроса.
В рамках настройки CRM и проверки интеграций мы связываем решение по каждому полю с маршрутами, которые в него записывают. Если этап также используется для оценки платной рекламы, заранее согласуйте значение этого статуса. Заполненное поле не подтверждает продажу или достоверный рекламный результат.
Что проверять после изменения
Сопоставьте требование с решением, которое оно должно поддерживать. Сравнивайте записи и маршруты одного типа до и после изменения. Оставляйте непроверенные маршруты видимыми и повторяйте затронутые проверки после соответствующего изменения правила или интеграции. Сохраняйте первоначальные ограничения успешно пройденной ручной проверки.
- Помогают ли значения следующему сотруднику принять решение или люди вводят заглушки?
- Видит ли ответственный сотрудник незавершённые или отклонённые записи и может ли их исправить?
- Остаётся ли честное обозначение неизвестного видимым и связано ли оно с согласованным следующим действием?
- Для каких этапов, участников или маршрутов записи всё ещё нет зафиксированного результата?
Эти наблюдения помогают принять следующее решение по конфигурации. Они не подтверждают улучшение продаж и не доказывают истинность каждого введённого значения.
Где подключаемся мы
Мы начинаем с назначения поля, этапа, на котором информация становится известна, и сотрудника, которому она нужна. Затем сопоставляем это решение с существующей настройкой и проверкой каждого используемого маршрута. Запишите проблемный этап, недостающую информацию и все маршруты записи данных. Чтобы сформулировать вопрос, не нужны экспорт клиентских данных или учётные данные аккаунта.
