Ein Workflow in Bitrix24 (Alaio) kennt immer den Datensatz, auf dem er läuft — und fast nichts über die Datensätze drumherum. Dabei beginnt die Hälfte der realen Szenarien mit einer Suche: Existiert dieser Kunde schon, gibt es einen offenen Auftrag zu ihm, wurde die Follow-up-Aufgabe bereits angelegt? Der Standard-Designer hat keinen Suchschritt, also überspringen Prozesse die Prüfung und züchten Dubletten — oder sie weichen auf externe Skripte aus. Dieser Leitfaden zeigt, wie Find-Roboter die Lücke schließen: nach beliebigem Feld suchen, ID und Gefunden-Flag erhalten, dann verzweigen, verknüpfen und aktualisieren.
Warum aus einem Workflow nach Datensätzen suchen?
Weil der auslösende Datensatz selten die ganze Geschichte ist. Eine neue Anfrage kommt als Lead an, doch die Person ist vielleicht längst ein Kontakt mit Kaufhistorie. Eine Support-Anfrage verweist auf ein Unternehmen mit einem offenen Auftrag, an den der Prozess andocken sollte, statt ihn zu duplizieren. Ein Phasenwechsel soll die Follow-up-Aufgabe aktualisieren — falls es sie gibt. In jedem Fall braucht der Workflow die Antwort auf „gibt es einen Datensatz, in dem Feld X den Wert Y hat“ — und der Wert kommt aus den Feldern des aktuellen Datensatzes.
Wie funktioniert die Suche nach Bedingung?
Ein Roboter-Aufruf pro Suche. Kontakt per Telefon/E-Mail finden findet Personen über ihre stabilsten Identifikatoren; Auftrag nach Bedingung finden und Lead nach Bedingung finden suchen über ein konfigurierbares Feld-Wert-Paar. Jeder liefert zwei Dinge in Workflow-Variablen zurück: die ID des gefundenen Datensatzes und ein Y/N-Gefunden-Flag. Das Flag macht das Muster sicher — der Prozess verzweigt explizit darauf (Bedingungsmechanik hier), und für zusammengesetzte Prüfungen wie „gefunden AND Phase ist offen“ gibt es Komplexe Bedingung (AND / OR / NOT). Eine praktische Voraussetzung: Die Suche per Telefon funktioniert nur bei einheitlich gespeicherten Nummern — machen Sie zuerst den Formatierungsdurchgang für Telefonnummern, sonst sehen gleiche Nummern für den Vergleich verschieden aus.
Was macht man mit der gefundenen ID?
Die ID ist der Griff für jeden weiteren Schritt. Update-Roboter — Auftrag per ID aktualisieren, Kontakt per ID aktualisieren — schreiben Felder auf den gefundenen Datensatz, nicht auf den aktuellen. Feldwert einer verknüpften Entität abrufen und Feldwert einer verknüpften Entität setzen bewegen Daten zwischen beiden. Und wurde nichts gefunden, legt der Sonst-Zweig den Datensatz mit Bordmitteln an — auf beiden Pfaden konvergiert der Prozess zu „genau ein Datensatz, aktuelle Daten“.
Wie verhindert die Suche Dubletten?
Suchen-vor-Anlegen ist die günstigste Dublettenabwehr überhaupt: eine Suche am Eingang schlägt jede Zusammenführungskampagne im Nachhinein. Die eingebaute Dublettenkontrolle fängt einiges bei manueller Eingabe ab, doch Datensätze aus Importen, Formularen und Integrationen fließen daran vorbei — ein Workflow mit Kontakt per Telefon/E-Mail finden davor ist das Netz, das den Rest fängt. Was mit bereits vorhandenen Dubletten zu tun ist, ist ein eigenes Handwerk — beschrieben im Leitfaden zum Finden und Zusammenführen.
Funktioniert das auch für Aufgaben und Smart-Prozesse?
Ja, dasselbe Muster reicht über das klassische CRM hinaus. Aufgabe nach Bedingung finden beantwortet „gibt es schon ein offenes Follow-up“, bevor der Prozess das nächste anlegt. Smart-Prozess-Element finden durchsucht Datensätze eigener Entitäten — Abonnements, Lieferungen, Assets —, die für den Standard-Designer aus den Workflows anderer Entitäten unsichtbar sind; was Smart-Prozesse sind und wann man sie einsetzt, steht im Leitfaden zu Smart-Prozessen.
Wie geht es weiter?
Bauen Sie noch heute eine Suche in Ihren Eingangsprozess ein: die Kontaktsuche vor der Lead-Konvertierung zahlt sich noch in derselben Woche aus. Weitere Suchen-dann-Handeln-Rezepte sammeln die Automatisierungsbeispiele, und der komplette Satz an Such-, Update- und Verknüpfungsrobotern steht im Katalog.