Pola wymagane HubSpot należy ustawiać w punkcie, w którym ktoś może zgodnie z prawdą podać informacje potrzebne do podjęcia następnej decyzji. Przy ręcznej zmianie etapu transakcji należy użyć odpowiedniego ustawienia etapu, a przed wdrożeniem sprawdzić brakujące i kompletne wartości. Automatyczne wprowadzanie danych wymaga osobnej kontroli, ponieważ skonfigurowana reguła i ścieżka programowa używana do przesyłania danych mogą wpływać na rezultat.
Transakcja jest gotowa do przejścia dalej, ale ekran wymaga informacji, których nikt jeszcze nie zna. W innym miejscu rekord trafia do kolejnej osoby z pustym polem. Zaczynamy od zapisania decyzji, do której potrzebne są te informacje. Ten poradnik dotyczy wymagań związanych z etapami transakcji; formularz witryny lub panel tworzenia rekordu mają własne ustawienia.
Którą regułę pól wymaganych HubSpot Państwo zmieniają?
Przed wyborem ustawienia należy określić, kiedy informacja jest potrzebna. W przewodniku HubSpot po lejku sprzedażowym rozróżniono wyświetlanie pola na danym etapie od wymagania jego wartości. Przewodnik po formularzu tworzenia opisuje wymagania obowiązujące przy ręcznym tworzeniu rekordu. Te mechanizmy działają w różnych momentach: przy pierwszym wprowadzeniu i późniejszym przekazaniu mogą być potrzebne inne informacje.
Właściwość to pole w rekordzie. Lejek sprzedażowy to sekwencja etapów, przez które przechodzi transakcja. Poniższe rozróżnienia pomagają zapytać administratora o istniejącą konfigurację.
| Mechanizm | Pytanie, na które odpowiada |
|---|---|
| Wymaganie formularza tworzenia | Co trzeba wpisać podczas ręcznego tworzenia rekordu? |
| Warunkowa właściwość etapu | Co powinno się pojawić lub być wymagane podczas ręcznego tworzenia rekordu na tym etapie albo przenoszenia go na ten etap? |
| Logika warunkowa właściwości | O jakie inne pola należy poprosić, gdy właściwość sterująca spełnia warunek? |
| Przełącznik Required w formularzu witryny | Co odwiedzający musi uzupełnić, aby wysłać formularz? |
| Walidacja wartości | Czy wprowadzona wartość spełnia obsługiwaną regułę formatu lub zakresu? |
HubSpot opisuje je jako odrębne mechanizmy o osobnej dostępności i zakresie działania. Samo pojawienie się pola na ekranie nie dowodzi, że blokuje ono zapis. Niepuste pole nadal musi zawierać sensowną odpowiedź.
Proszę ustalić, co musi wiedzieć kolejna osoba
Należy opisać planowaną decyzję zwykłym językiem, a następnie wskazać informacje potrzebne do jej podjęcia. Dla każdego proponowanego pola wymaganego warto zapisać, kto korzysta z odpowiedzi, kiedy można ją poznać i co wyjaśnia użyteczna wartość. Jeśli nikt nie potrafi wyjaśnić zastosowania pola, wymaganie powinno pozostać do weryfikacji.
Na przykład przed przygotowaniem oferty pracownik może potrzebować jasnego opisu oczekiwań potencjalnego klienta. Należy uzgodnić, co taki opis ma zawierać. Wymaganie wcześniej odpowiedzi opartej na domysłach pozostawiłoby decyzję nierozstrzygniętą, nawet gdyby pole zawierało tekst.
Trzeba zachować wyraźny sposób obsługi informacji, które nadal są nieznane. Należy poprosić osobę odpowiedzialną o ponowne rozważenie etapu lub momentu działania wymagania. Przed zmianą reguły należy zachować istniejące dane i sprawdzić zależności; usuwanie pól i dodawanie fikcyjnych wartości nie należą do tej procedury.
Jeśli sprzeczne rekordy utrudniają ustalenie, czyje informacje są zmieniane, najpierw trzeba rozwiązać kwestię tożsamości. Nasz osobny poradnik dotyczący weryfikacji zduplikowanych kontaktów HubSpot wyjaśnia, dlaczego scalenie wymaga własnych kontroli.
Proszę ustawić pole dla właściwego etapu transakcji
Należy zastosować udokumentowaną przez HubSpot procedurę dotyczącą etapów, korzystając z pomocy już wyznaczonego, upoważnionego administratora. Zgodnie z przewodnikiem po lejku potrzebne są uprawnienie Edit property settings oraz istniejąca, edytowalna właściwość zależna. Przed rozpoczęciem trzeba sprawdzić faktyczną subskrypcję konta i dostępność obiektu; brak mechanizmu jest powodem do kontaktu z administratorem, a nie do zakupu wyższego planu na podstawie założenia.
Przed wprowadzeniem zmian należy zapisać poprzednią regułę i uzgodnić sposób jej przywrócenia. Trzeba przygotować zatwierdzone rekordy testowe w środowisku, w którym kontrole nie mogą kontaktować się z klientami, uruchamiać kampanii lub naliczeń ani zmieniać raportów produkcyjnych. Jeśli taka izolacja jest niedostępna, przed testami należy poprosić administratora o jej przygotowanie.
- Proszę otworzyć Settings, a następnie Data Management i Objects. Wybrać odpowiedni obiekt oraz jego kartę Pipelines.
- Proszę wybrać właściwy lejek. W wierszu etapu docelowego otworzyć Add rule w sekcji Conditional logic rules.
- Proszę potwierdzić warunek etapu, a następnie dodać właściwość zależną. Wybrać Required, jeżeli brak wartości ma uniemożliwiać objętą regułą czynność ręczną.
- Proszę wybrać Save logic i dokładnie odnotować etap oraz właściwość objęte regułą.
Według tego samego przewodnika właściwości tylko do odczytu, w tym wartości obliczeniowe i punktowe, nie mogą pełnić funkcji właściwości etapu. Jeśli pole jest niedostępne, przed utworzeniem kolejnego pola o tym samym przeznaczeniu należy sprawdzić jego definicję.
Proszę sprawdzić brakujące i kompletne wartości przed wdrożeniem
Uzgodniony warunek należy przetestować za pomocą zatwierdzonego rekordu syntetycznego, zapisując oczekiwany wynik przed wykonaniem czynności. Najpierw należy pozostawić wybrane pole puste, a następnie podać sensowną wartość testową. Po ponownym otwarciu rekordu trzeba sprawdzić zapisany etap i pole. Wynik dotyczy wyłącznie faktycznie sprawdzonych warunków, osoby lub systemu oraz ścieżki.
- Proszę spróbować objętej regułą ręcznej zmiany etapu przy braku wartości zależnej. Odnotować, czy odpowiedni komunikat uniemożliwia zapis; nieoczekiwany wynik pozostaje otwartym problemem.
- Proszę podać wyraźnie fikcyjną wartość testową, która nadal odpowiada uzgodnionemu znaczeniu. Powtórzyć czynność i sprawdzić zapisane dane.
- Proszę osobno sprawdzić etap spoza skonfigurowanego warunku, aby ujawnić ewentualne nieoczekiwanie szerokie wymaganie.
- Proszę przechowywać razem stan początkowy, oczekiwany wynik, zaobserwowany wynik oraz osobę odpowiedzialną za każdą niezgodność.
Tego samego rekordu należy używać ostrożnie, aby wcześniej zapisana wartość nie unieważniła późniejszego testu braku wartości. Administrator powinien przygotować zamierzony stan początkowy. Samo ukończenie działania na ekranie nie jest wystarczającym dowodem zapisanego rezultatu.
Proszę sprawdzić ścieżki zapisujące dane w rekordach
Powodzenie czynności ręcznej nie dowodzi, jak wymaganie obsłuży workflow, import, formularz witryny lub konektor. Workflow to zautomatyzowany proces w HubSpot, a API to interfejs programowy, którego konektor może używać do zapisywania rekordów. Przewodnik HubSpot po właściwościach warunkowych wyłącza modyfikacje wykonywane przez workflow z opisanego zakresu czynności ręcznych.
Dziennik zmian dla deweloperów opisuje egzekwowanie skonfigurowanych warunkowych właściwości wymaganych i wymagań dotyczących tworzenia rekordów w wersji API 2026-09, przy czym wymagania tworzenia dotyczą żądań POST. Znaczenie mają rzeczywista ścieżka oraz wersja używana przez konektor.
Osobę utrzymującą każdą używaną ścieżkę należy poprosić o wskazanie reguły i przeprowadzenie zatwierdzonych testów z brakującymi oraz kompletnymi danymi wejściowymi. Nie trzeba dodawać importu ani integracji tylko po to, by je przetestować. Dla każdej istniejącej ścieżki należy zachować osobny wynik, w tym zwrócony komunikat oraz, jeśli można je sprawdzić, zapisany etap i wartość.
Dziennik zmian API odradza ponawianie tego samego odrzuconego żądania bez zmian. Jeśli zapis zostanie odrzucony, należy zachować zapytanie w ramach zatwierdzonego procesu i przypisać poprawkę widocznemu właścicielowi. Przed ponownym testem trzeba zbadać brakującą informację lub mapowanie; nie należy osłabiać reguły tylko po to, by żądanie zostało przyjęte.
W ramach kontroli konfiguracji i integracji CRM łączymy każdą decyzję dotyczącą pola ze ścieżkami, które je zapisują. Jeśli etap zasila również pomiar płatnych kampanii reklamowych, przed użyciem statusu należy uzgodnić jego znaczenie. Wypełnienie pola nie dowodzi sprzedaży ani prawidłowego wyniku reklamowego.
Co należy sprawdzić po zmianie
Wymaganie należy ponownie ocenić względem decyzji, którą miało wspierać. Trzeba porównać takie same rodzaje rekordów i ścieżek przed zmianą i po niej. Niesprawdzone ścieżki powinny pozostać widoczne, a odpowiednie kontrole trzeba powtórzyć po zmianie reguły lub integracji. Należy zachować pierwotne ograniczenia pomyślnie zakończonej kontroli ręcznej.
- Czy wartości pomagają kolejnej osobie podjąć decyzję, czy pracownicy wpisują symbole zastępcze?
- Czy osoba odpowiedzialna widzi niekompletne lub odrzucone zapisy i może je poprawić?
- Czy uczciwie oznaczona niewiadoma pozostaje widoczna wraz z uzgodnioną kolejną czynnością?
- Dla których etapów, osób lub ścieżek zapisu nadal nie ma zarejestrowanego wyniku?
Te obserwacje wspierają następną decyzję konfiguracyjną. Nie dowodzą poprawy sprzedaży ani prawdziwości każdej wprowadzonej wartości.
Gdzie możemy pomóc
Zaczynamy od celu pola, etapu, na którym informacja staje się znana, oraz osoby, która jej potrzebuje. Łączymy tę decyzję z istniejącym ustawieniem i kontrolą każdej używanej ścieżki. Proszę zapisać problematyczny etap, brakującą informację oraz wszystkie ścieżki zapisujące rekord. Do zdefiniowania problemu nie są potrzebne eksporty danych klientów ani dane dostępowe do konta.
