Wenn ein Roboter in Bitrix24 „nicht funktioniert", ist er in den meisten Fällen entweder gar nicht gestartet oder er ist gestartet und durch eine Bedingung gestoppt worden — und das sind zwei verschiedene Diagnosezweige. Unterschieden werden sie durch das Protokoll, deshalb muss die Pipeline nicht auf gut Glück repariert werden. Wir gehen Schritt für Schritt vor: Roboter-Protokoll in der Karte, Phase, Rückwirkung, Startbedingungen, Rechte und Tarif, entfernte Quell-App. Für jedes Symptom gibt es eine konkrete Prüfung.

Womit anfangen: das Roboter-Protokoll in der Karte

Die erste Frage der Diagnose lautet: Ist der Roboter überhaupt gestartet? Die Antwort liefert das Protokoll „Roboter" in der Karte des Elements: welche Roboter gestartet sind, wann und womit sie geendet haben. Drei Ausgänge — drei verschiedene Richtungen. Kein Eintrag — der Roboter ist nicht gestartet: prüfen Sie Phase, Pipeline und Rückwirkung, das sind die nächsten beiden Abschnitte. Es gibt einen Eintrag, der mit einem Fehler endete — lesen Sie den Text: meist sind es die Rechte des Ausführenden oder fehlerhafte Parameter, dazu der Abschnitt zur Umgebung weiter unten. Es gibt einen Eintrag, der Status ist erfolgreich, aber es gibt „keine Wirkung" — der Roboter hat genau das getan, was eingestellt ist, nur ist eben das Falsche eingestellt: öffnen Sie die Parameter und gleichen Sie Felder, Werte und Empfänger mit den Erwartungen ab.

Steht der Roboter in der falschen Phase?

Roboter sind an eine Phase gebunden und lösen in dem Moment aus, in dem das Element auf sie gelangt. Daher die typischen Fehlgriffe. Der Roboter ist in einer anderen Pipeline eingerichtet: jede Pipeline hat ihren eigenen Satz an Robotern — prüfen Sie, ob Sie diejenige bearbeitet haben, in der der Deal lebt. Der Roboter steht in einer Phase, durch die der Deal nicht hindurchgeht: beim Verschieben der Karte über mehrere Spalten auf einmal lösen die Roboter der Zielphase aus, die dazwischenliegenden bleiben unberührt. Der Deal stand bereits in der Phase, als der Roboter hinzugefügt wurde — das ist ein gesonderter Fall, dazu der nächste Abschnitt. Die grundlegende Einrichtung von Robotern und ihr Unterschied zu Triggern stehen im Artikel über Roboter.

Warum wirkt der Roboter nicht rückwirkend?

Ein Roboter ist eine Reaktion auf das Ereignis „Element ist auf die Phase gelangt". Wenn man einen Roboter zu einer Phase hinzufügt, in der bereits zwanzig Deals stehen, ist das Ereignis für sie längst vergangen — der neue Roboter löst für sie nicht aus. Das ist kein Fehler, sondern reguläres Verhalten: rückwirkend starten Roboter nicht. Was man mit den alten Karten tut: auf eine benachbarte Phase verschieben und zurückholen — das Ereignis tritt erneut ein; für die Massenverarbeitung markieren Sie die Deals in der Liste und ändern die Phase per Gruppenoperation. Und eine Regel für die Zukunft: nachdem Sie einen Roboter hinzugefügt oder geändert haben, schicken Sie sofort einen Test-Deal durch die Phase — warten Sie nicht, bis die Abweichung im Echtbetrieb auftaucht.

Eine Bedingung hat blockiert: was sieht der Roboter wirklich?

Startbedingungen filtern das Auslösen, und der Ausschluss entsteht fast immer durch eine Abweichung der Daten von den Erwartungen: ein Feld, das „ganz sicher ausgefüllt" ist, ist im Moment des Eintritts in die Phase noch leer; der Wert kommt in einem anderen Format an; der Vergleich hat das falsche Feld erwischt. Mit den Einstellungen zu streiten ist sinnlos — schauen Sie sich die Daten mit den Augen des Prozesses an. Der Roboter „Feld auf Befüllung prüfen" nimmt Entitätstyp, ID und Feldcode entgegen und gibt eine Kennung Y/N plus den aktuellen Wert zurück: setzen Sie ihn ohne Bedingungen in die Phase — das Protokoll zeigt, was im Moment des Auslösens tatsächlich im Feld liegt. Eine Kombination von Prüfungen führt „Komplexe Bedingung (AND / OR / NOT)" aus: bis zu vier Vergleiche mit AND/OR-Logik und ein zusammenfassendes Y/N. Danach repariert man nicht die Pipeline, sondern die Daten oder die Bedingung selbst.

Rechte, Tarif oder entfernte App?

Wenn das Protokoll Fehler zeigt — schauen Sie auf die Umgebung, nicht auf die Logik. Der Roboter führt eine Aktion im Namen des zugewiesenen Benutzers aus: fehlen die Rechte auf das Element, den Bereich oder den Phasenwechsel — schlägt die Aktion fehl. Die Automatisierung hängt vom Tarif ab: nach dem Wechsel auf einen einfacheren Plan ist ein Teil der Roboter nicht mehr verfügbar — gleichen Sie die Möglichkeiten des aktuellen Tarifs ab. Ein Sonderfall sind Roboter, die von Apps aus dem Bitrix24.Market installiert wurden: wurde die Quell-App gelöscht oder ist das Market-Abonnement abgelaufen, verschwinden ihre Roboter aus den Vorlagen oder werden nicht mehr ausgeführt — prüfen Sie die Liste der installierten Apps. Und denken Sie daran, dass ein Trigger kein Roboter ist: wenn sich die Karte nicht einmal in die Phase bewegt, diagnostizieren Sie die Trigger.

Checkliste

Protokoll „Roboter" in der Karte: ist der Roboter gestartet und mit welchem Ergebnis. Pipeline und Phase: der Roboter steht dort, wo der Deal tatsächlich durchgeht. Rückwirkung: auf alte Deals wirkt der Roboter nicht — schicken Sie sie erneut durch die Phase. Bedingungen: prüfen Sie die tatsächlichen Feldwerte mit einem Diagnose-Roboter, nicht aus dem Gedächtnis. Umgebung: Rechte des Ausführenden, Tarif, ist die Quell-App noch aktiv. Diagnose-Bausteine — Befüllungsprüfung, komplexe Bedingung — finden Sie im Roboteka-Katalog: kostenlose Installation aus dem Bitrix24.Market. Fehlt der passende — beschreiben Sie die Aufgabe, wir bauen den Roboter kostenlos.