Налаштовуйте обов’язкові поля HubSpot у той момент, коли хтось може правдиво надати інформацію, потрібну для наступного рішення. Для ручної зміни етапу угоди скористайтеся відповідним налаштуванням етапу, а перед упровадженням перевірте відсутні та заповнені значення. Автоматичне внесення даних потрібно перевіряти окремо, оскільки налаштоване правило та програмний маршрут передавання даних можуть вплинути на результат.
Угода готова перейти далі, але екран запитує відомості, яких ще ніхто не знає. В іншому місці запис надходить до наступного колеги з порожнім полем. Ми починаємо з опису рішення, для якого потрібна ця інформація. Цей посібник стосується вимог на етапах угоди; форма на сайті та панель створення запису мають власні налаштування.
Яке правило обов’язкових полів HubSpot ви змінюєте?
Перш ніж вибирати налаштування, визначте, коли саме потрібна інформація. У посібнику HubSpot щодо воронок розрізняються показ поля на певному етапі та вимога заповнити його значення. Посібник із форми створення описує вимоги під час ручного створення запису. Ці засоби діють у різні моменти: під час першого внесення та подальшої передачі можуть бути потрібні різні відомості.
Властивість - це поле в записі. Воронка - це послідовність етапів, якими рухається угода. Скористайтеся наведеними нижче відмінностями, коли запитуватимете адміністратора про вже наявні налаштування.
| Засіб | На яке запитання він відповідає |
|---|---|
| Вимога форми створення | Що потрібно ввести, коли хтось вручну створює запис? |
| Умовна властивість етапу | Що має відображатися або бути обов’язковим, коли хтось вручну створює запис на цьому етапі чи переміщує його на цей етап? |
| Умовна логіка властивостей | Які інші поля потрібно запитати, коли керівна властивість відповідає умові? |
| Перемикач Required у формі сайту | Що має заповнити відвідувач, щоб надіслати форму? |
| Перевірка значення | Чи відповідає введене значення підтримуваному правилу формату або діапазону? |
HubSpot описує їх як окремі засоби з власними умовами доступності та межами застосування. Поява поля на екрані не доводить, що воно блокує збереження. Навіть непорожнє поле має містити змістовну відповідь.
Визначте, що потрібно знати наступному колезі
Опишіть передбачене рішення звичайними словами, а потім назвіть інформацію, необхідну для його прийняття. Для кожного запропонованого обов’язкового поля запишіть, хто використовує відповідь, коли її можна дізнатися та що пояснює корисне значення. Якщо ніхто не може пояснити призначення поля, залиште вимогу на перегляді.
Наприклад, перед підготовкою пропозиції колезі може знадобитися чіткий опис запиту потенційного клієнта. Узгодьте, що має містити цей опис. Якщо вимагати здогадку раніше, рішення залишиться невирішеним, навіть коли поле міститиме текст.
Збережіть чіткий спосіб опрацювання інформації, яка досі невідома. Попросіть відповідальну особу переглянути етап або час спрацювання вимоги. Перед зміною правила збережіть наявні дані та перевірте залежності; видалення полів або додавання фіктивних значень не належить до цієї процедури.
Якщо через суперечливі записи незрозуміло, чиї дані ви змінюєте, спочатку розв’яжіть питання ідентифікації. Наш окремий посібник із перевірки дублікатів контактів HubSpot пояснює, чому об’єднання потребує власних перевірок.
Налаштуйте поле для потрібного етапу угоди
Виконайте документовану HubSpot процедуру налаштування етапу разом із чинним уповноваженим адміністратором. Згідно з посібником щодо воронок, потрібні дозвіл Edit property settings і наявна редагована залежна властивість. Перш ніж продовжити, перевірте фактичну передплату облікового запису та доступність об’єкта; відсутність потрібного засобу є причиною звернутися до адміністратора, а не купувати дорожчий план на підставі припущення.
Перед будь-якою зміною зафіксуйте попереднє правило й узгодьте спосіб його відновлення. Підготуйте затверджені тестові записи в середовищі, де перевірки не можуть зв’язатися з клієнтами, запустити кампанії чи списання або змінити робочу звітність. Якщо такої ізоляції немає, попросіть адміністратора підготувати її до тестування.
- Відкрийте Settings, потім Data Management і Objects. Виберіть потрібний об’єкт і його вкладку Pipelines.
- Виберіть потрібну воронку. У рядку цільового етапу відкрийте Add rule у розділі Conditional logic rules.
- Підтвердьте умову етапу, а потім додайте залежну властивість. Виберіть Required, якщо відсутність значення має перешкоджати охопленій ручній дії.
- Виберіть Save logic і точно запишіть, якого етапу та властивості стосується правило.
Згідно з тим самим посібником, властивості лише для читання, зокрема обчислювані та рейтингові значення, не можна використовувати як властивості етапу. Якщо поле недоступне, перевірте його визначення, перш ніж створювати інше поле з тим самим призначенням.
Перевірте відсутні й заповнені значення до впровадження
Перевірте узгоджену умову на затвердженому синтетичному записі та зафіксуйте очікуваний результат до виконання дії. Спочатку залиште вибране поле порожнім, а потім введіть змістовне тестове значення. Після повторного відкриття запису перевірте збережені етап і поле. Результат стосується лише фактично перевірених умови, особи чи системи та маршруту.
- Спробуйте виконати охоплену правилом ручну зміну етапу без значення залежної властивості. Зафіксуйте, чи відповідний запит перешкоджає збереженню; неочікуваний результат залишається відкритою проблемою.
- Введіть явно вигадане тестове значення, яке все ж відповідає узгодженому змісту. Повторіть дію та перевірте збережені дані.
- Окремо перевірте етап поза налаштованою умовою, щоб виявити неочікувано широку дію вимоги.
- Зберігайте разом початковий стан, очікуваний результат, спостережений результат і відповідальну за кожну невідповідність особу.
Обережно використовуйте той самий запис, щоб раніше збережене значення не зробило недійсною подальшу перевірку відсутнього значення. Попросіть адміністратора підготувати потрібний початковий стан. Саме лише завершення дії на екрані не є достатнім доказом збереженого результату.
Перевірте маршрути, що записують дані
Успішна ручна дія не доводить, як із вимогою працюють workflow, імпорт, форма сайту чи конектор. Workflow - це автоматизований процес у HubSpot; API - програмний інтерфейс, який конектор може використовувати для запису даних. Посібник HubSpot з умовних властивостей виключає зміни через workflow з описаного охоплення ручних дій.
У журналі змін для розробників описане застосування налаштованих умовних обов’язкових властивостей і вимог до створення записів у версії API 2026-09, причому вимоги до створення застосовуються до запитів POST. Фактичний маршрут і версія, які використовує конектор, мають значення.
Попросіть відповідального за кожен використовуваний маршрут визначити правило та виконати затверджені перевірки з відсутніми й повними вхідними даними. Не потрібно додавати імпорт або інтеграцію лише заради тестування. Зберігайте окремий результат для кожного наявного маршруту, зокрема повернене повідомлення, а також збережені етап і значення, якщо їх можна переглянути.
Журнал змін API не рекомендує повторно надсилати той самий відхилений запит без змін. Якщо операцію запису відхилено, збережіть звернення потенційного клієнта за затвердженим процесом і призначте відповідального за виправлення. Перед повторною перевіркою дослідіть відсутню інформацію або зіставлення; не послаблюйте правило лише для того, щоб запит пройшов.
Під час перевірки налаштувань та інтеграцій CRM ми пов’язуємо кожне рішення щодо поля з маршрутами, які записують у нього дані. Якщо етап також використовується для вимірювання платної реклами, узгодьте значення цього статусу до його використання. Заповнення поля не доводить ані продажу, ані коректного рекламного результату.
Що переглянути після зміни
Перегляньте вимогу з огляду на рішення, яке вона мала підтримати. Порівняйте однакові типи записів і маршрутів до та після зміни. Залишайте неперевірені маршрути видимими й повторюйте відповідні перевірки після зміни правила або інтеграції. Зберігайте початкові обмеження успішної ручної перевірки.
- Чи корисні значення для рішення наступного колеги, чи люди вводять заповнювачі?
- Чи може відповідальна особа побачити неповні або відхилені записи та виправити їх?
- Чи залишається чесно позначена невідомість видимою разом з узгодженою наступною дією?
- Для яких етапів, учасників або маршрутів запису досі немає зафіксованого результату?
Ці спостереження допомагають ухвалити наступне рішення щодо налаштувань. Вони не доводять поліпшення продажів і не підтверджують правдивість кожного введеного значення.
Де ми можемо допомогти
Ми починаємо з призначення поля, етапу, на якому інформація стає відомою, та людини, якій вона потрібна. Ми пов’язуємо це рішення з наявним налаштуванням і перевіркою кожного використовуваного маршруту. Запишіть проблемний етап, відсутню інформацію й усі маршрути, що записують дані. Щоб визначити питання, не потрібні ані експорти клієнтських даних, ані облікові дані для доступу.
