Proces w Bitrix24 (Alaio) zawsze zna rekord, na którym działa — i prawie nic o rekordach wokół niego. Tymczasem połowa realnych scenariuszy zaczyna się od wyszukania: czy ten klient już istnieje, czy ma otwarty deal, czy zadanie follow-up zostało już utworzone? Standardowy projektant nie ma kroku wyszukiwania, więc procesy albo pomijają sprawdzenie i hodują duplikaty, albo idą przez zewnętrzne skrypty. Ten przewodnik pokazuje, jak lukę domykają roboty wyszukiwania: szukaj po dowolnym polu, odbierz ID i flagę znalezienia, potem rozgałęziaj, wiąż i aktualizuj.

Po co szukać rekordów z poziomu procesu?

Bo rekord wyzwalający rzadko jest całą historią. Nowe zapytanie przychodzi jako lead, ale ta osoba może już być kontaktem z historią zakupów. Zgłoszenie supportowe wskazuje firmę z otwartym dealem, do którego proces powinien się podpiąć, zamiast go dublować. Zmiana etapu powinna zaktualizować zadanie follow-up — o ile istnieje. W każdym przypadku proces potrzebuje odpowiedzi na pytanie „czy istnieje rekord, w którym pole X równa się wartości Y", a wartość pochodzi z pól bieżącego rekordu.

Jak działa wyszukiwanie według warunku?

Jedno wywołanie robota na jedno wyszukanie. Znajdź kontakt po telefonie/e-mailu dopasowuje osoby po ich najstabilniejszych identyfikatorach; Znajdź deal według warunku i Znajdź lead według warunku szukają po skonfigurowanej parze pole–wartość. Każdy zwraca do zmiennych procesu dwie rzeczy: ID znalezionego rekordu i flagę znalezienia Y/N. To flaga czyni wzorzec bezpiecznym — proces rozgałęzia się na niej jawnie (mechanika warunków tutaj), a do bramek złożonych w rodzaju „znaleziono AND etap jest otwarty" służy Warunek złożony (AND / OR / NOT). Jeden praktyczny warunek wstępny: wyszukiwanie po telefonie działa tylko przy jednolicie zapisanych numerach — najpierw wykonaj przebieg formatowania numerów, inaczej równe numery będą dla porównania różne.

Co zrobić ze znalezionym ID?

ID to uchwyt dla każdego kolejnego kroku. Roboty aktualizacji — Aktualizuj deala według ID, Aktualizuj kontakt według ID — zapisują pola znalezionego rekordu, nie bieżącego. Pobierz wartość pola powiązanej encji i Ustaw wartość pola powiązanej encji przenoszą dane między nimi. A gdy nic nie znaleziono, gałąź „inaczej" tworzy rekord narzędziami standardowymi — proces na obu ścieżkach zbiega do stanu „dokładnie jeden rekord, aktualne dane".

Jak wyszukiwanie zapobiega duplikatom?

Znajdź-zanim-utworzysz to najtańsza deduplikacja, jaka istnieje: jedno wyszukanie na wejściu bije kampanię scalania po fakcie. Wbudowana kontrola duplikatów łapie część przypadków przy ręcznym wprowadzaniu, ale rekordy z importów, formularzy i integracji przepływają obok niej — proces z robotem Znajdź kontakt po telefonie/e-mailu na przedzie to siatka, która wyłapuje resztę. Co zrobić z duplikatami, które już są w bazie, to osobne rzemiosło, opisane w przewodniku po wyszukiwaniu i scalaniu duplikatów.

Czy to działa dla zadań i procesów smart?

Tak, ten sam wzorzec wykracza poza klasyczny CRM. Znajdź zadanie według warunku odpowiada na pytanie „czy otwarty follow-up już jest", zanim proces utworzy następny. Znajdź element procesu inteligentnego przeszukuje rekordy encji niestandardowych — subskrypcje, wysyłki, zasoby — których standardowy projektant nie widzi z procesów innych encji; czym są procesy smart i kiedy ich używać, wyjaśnia przewodnik po procesach smart.

Co dalej?

Wepnij jedno wyszukiwanie do procesu przyjmowania zgłoszeń już dziś: znajdowanie kontaktu przed konwersją leada zwraca się w tym samym tygodniu. Więcej przepisów „wyszukaj, potem działaj" zebrano w przykładach automatyzacji, a pełen zestaw robotów wyszukiwania, aktualizacji i powiązań mieszka w katalogu.