Community

Support » Forum » Bitrix24 Community » Learnings aus dem letzten Projekt - CRM
Seiten: 1
RSS
Learnings aus dem letzten Projekt - CRM, Automatisierung & Workflow starten gelöst
Hallo liebe Bitrix 24 Nutzer,
da ich an der ein oder anderen Stelle bereits von euch profitieren konnte, möchte ich an dieser Stelle auch etwas zurück geben und euch meine Learnings aus meinem letzten Projekt im Bezug auf Automatisierungen innerhalb des CRMs preisgeben.
In anderen Threads habe ich häufig gelesen, dass Workflows für viele Nutzer Fluch und Segen zugleich sind. Vor allem einige Funktionen wie beispielsweise "Workflow starten" (Run Workflow) sind für viele ein Rätsel, welches ich heute lüften möchte.Um aber meine Lösung verstehen zu können, möchte ich an dieser Stelle kurz die Gegebenheiten des Projektes erläutern:
Bei dem Projekt stand das CRM Dashboard / KanBan im Fokus. Hierbei sollten Leads automatisiert weitergereicht werden und gleichzeitig während der Ausführung weitere Workflows gestartet werden. Diese umständliche Verkettung war den Support-Auflagen der Haus eigenen IT geschuldet, da CRM Workflows nicht so gut protokolliert werden wie normale Workflows (Automatisierungsregeln werden nämlich gar nicht dokumentiert). Somit war die Herausforderung das KanBan in ein Gemisch aus KanBan und schreibgeschützten Dashboard umzuwandeln, mithilfe die Vertriebler zu jedem Zeitpunkt sehen konnten, wo aktuell ein Projekt steht. Darüber hinaus sollte es sie an Kontrollanrufe erinnern und eine komplette Projektbesetzung (Anbindung an Nutzer) ermöglichen.


1. Warum nicht mit Automatisierungsregeln?Diese Frage habe ich mir zu Beginn auch gestellt. Problematisch war wie eben beschrieben, dass die Dokumentationen der Workflows teilweise nur dürftig ist. Wenn sie nicht im Reiter aktive Workflows angezeigt werden, dann lohnt es sich auf jeden Fall schonmal bei den Leads selbst zu schauen, da diese einen Unterreiter Workflows haben, welcher eine Aussicht der durchlaufenen Workflows zulässt. Ein weiterese Problem bei den Automatisierungsregeln besteht in der CRM Funktion "Status ändern", da diese den Workflow direkt beendet (siehe Tooltipp der Funktion). Diese Problematik habe ich am Anfang vollkommen übersehen, was mich einige Zeit gekostet hat.


2. Lead übergreifender Workflow ohne AutomatisierungsregelnIn den Einstellungen des CRMs gibt es unter dem Reiter Automatisierung neben den Automatisierungsregeln von Lead, Auftrag und Angebot auch noch die Kachel Workflows. Innerhalb dieser kann man Workflow-Vorlagen für die Phase Leads bauen, welche mehrere Stati abdeckt. Ich persönlich habe diesen Weg genommen, da ich innerhalb dieses Workflow-Konfigurators alle Bausteine implementieren konnte und somit zugehörig zu Lead einen Workflow hatte, welcher nicht in der normalen Workflow Liste auftaucht, da er nur auf das CRM bezogen ist. Innerhalb dieses Workflows kann man mit der Funktion "Leadstatus wird erwartet" (das gleiche Prinzip gilt auch für "auf Auftragsstatus warten") Automatisierungen bauen, welche unabhängig von den Status-Automatisierungsregeln sind. Dennoch hat man an dieser Stelle immer noch das Problem, dass die Funktion "Status ändern" den Workflow abbricht, nachdem der Leadstatus geändert wurde. Wie umgeht man dieses Problem?


3. Workflow starten / Run WorkflowDieses Problem kann mit einem einfachen Trick umgangen werden. An dieser Stelle nutzen wir die Funktion "Workflow starten" ("Run Workflow") das erste Mal aus. Im Gegensatz zu Status ändern bricht man mit Workflow starten den Workflow nicht ab. Darüber hinaus kann man ihn sogar pausieren, sodass man sicher stellt, dass ein externer Workflow gestartet wird und komplett durchläuft, bevor es im ersten Workflow weiter geht. Will man nun das Abbruchsproblem von Status ändern nun umgehen erstellt man einfach einen Workflow in der Lead-Vorlage, welcher nur den Status ändert. Diesen Workflow (ich nenne ihn der Einfachheit halber Statusworkflow1) kann nun durch den Lead-übergreifenden-Workflow gestartet werden. Somit wird der Status durch Statusworkflow1 geändert, aber weitere Bausteine des Lead-übergreifenden-Workflows können nach der Status Änderung weiter ausgeführt werden.


3.1. Element IDElement ID ist ein Feld innerhalb der Funktion Workflow starten. Dank der guten Dokumentation und des überaus hilfreichen Supports von Bitrix *hust* kann man leider nicht auf den ersten Blick verstehen, was es mit diesem Feld auf sich hat. Nach gut 2 Tagen ausprobieren konnte ich dieses Problem letzten Endes ohne das Bezahlen eines Partners von Bitrix lösen, welcher mir zuvor am Telefon sogar noch falsche Informationen gegeben hatte.


3.2. Funktionsweise von Element IDDie Funktion Workflow starten funktioniert in zwei verschiedene Richtungen, wobei sie vom Grundgedanken gleich ist. Ähnlich dessen hat Element ID an sich eine Aufgabe, jedoch zwei verschiedene Herangehensweisen. Um einen Workflow zu starten gibt man vorher an, welchen Workflow man starten möchte. Bitrix unterscheidet hierbei zwischen CRM Workflows und normalen Workflows. Element ID ist hierbei das Bindeglied zwischen den zu startenden Workflow und dem Workflow, in welchem die Funktion Workflow starten verbaut wird. Element ID übernimmt hierbei die Rolle der Vererbung, was soviel bedeutet, dass Elemente / Variablen aus dem bsw. Lead-übergreifenden-Workflow an den zu startenden Workflow weiter gegeben werden. Dieser kann im Anschluss auf diese Daten zugreifen.Diese Information ist insofern wichtig, als dass Leadworkflows die Lead ID benötigen (gleiche Vorgehensweise bei Aufträgen) und Workflows außerhalb vom CRM Elemente benötigen. Im Falle des Leadworkflows ist das relativ simpel, da man bei Element ID nur "{=Document:ID}" eintragen muss.Im Falle des anderen Workflows verhält es sich so, dass man normalerweise einen Workflow im Activity Stream über die Eingabe gewisser Daten startet. In unserem Beispiel wäre das die Besetzung des Projektteams, welches aus verschiedenen Projektmitgliedern besteht. Diese Informationen kann man mithilfe der Element ID an den zu startenden Workflow vererben. Hierbei muss man einfach zuvor ein Element erstellen, welches die Listeninhalte des neuen Workflows hat (Element mit Liste im Bereich der Konstruktion). Dieses Element kann man nun im Anschluss durch die ID ansteuern - dazu gibt es im Menü der drei Punkte eine extra Beschreibung des Objektes.
Mit diesem Wissen kann man nun ohne Probleme Leads automatisiert durch die KanBan jagen.


Noch eine kleine Zugabe meiner Seite:


4. Vererbung mithilfe von voreingestellten ListenfeldernDiese Möglichkeit ist mir leider erst gegen Ende des Projektes aufgefallen. Hierbei kann man in den Einstellungen des CRMs benutzerdefinierte Felder zu Leads oder Aufträge anlegen. Wenn man nun beispielsweise auf dem Lead ein Auftrag machen will und dabei gewisse Dinge (wie beispielsweise die Projektbesetzung) mit in den Auftrag geben möchte, kann man diese Felder zuvor definieren und dann bei der Erstellung einfach via Variable automatisch befüllen.
4.1. Abrufen von benutzerdefinierten FeldernHier kommen wir zur eigentlichen Krux. Im Lead / Auftrag kann man über die Schaltfläche Dokumente -> Vorlage hinzufügen -> Felder alle Feldvariablen herausfinden und kopieren. Problem ist nur, dass die kopierten Felder nicht funktionieren, da sie nicht vom System erkannt werden. Da an dieser Stelle der Bitrix Support auch so hilfreich war wie zuvor, möchte ich diese Problematik auch noch schnell lösen. Hat man beispielsweise das Feld Projektleiter vorher definiert und möchte nun den Nutzer, der als Projektleiter besetzt wurde, ausgeben oder eine Nachricht automatisiert an diesen schicken, so findet man unter Dokumente -> Vorlage hinzufügen -> Felder -> Projektleiter meistens Folgendes (wichtig: Variable:Projektleiter ist in diesem Beispiel vom Typ anbinden an Nutzer):Projektleiter Name   {UFCRM0124751654}    Code kopieren     Source:UF.CRM.0124751651Klickt man nun auf kopieren erhält man die Bezeichnung in den geschwungenen Klammern. Diese Variable wird jedoch wie zuvor beschrieben vom System nicht erkannt. Der Trick ist nun ähnlich wie bei Befehlen wie {=Document:ASSIGNED_BY_ID} die Unterstriche einzufügen. Diese werden bei der vom System generierten Kopie komplett außer Acht gelassen und werden auch in keiner Dokumentation beschrieben. Richtig heißt unsere Variable Projektleiter also {UF_CRM_0124751654}, welche nun als Absender / Empfänger genutzt werden kann, oder mit {UF_CRM_0124751654 > printable} in einen Text eingebaut werden kann.


Ich hoffe ich konnte Ihnen damit ein wenig weiterhelfen. Wenn Sie weitere Fragen haben können Sie mich auch gerne über Xing (Maximilian Grieß aus Göttingen) kontaktieren.


LG und viel Erfolg beim Workflows bauen
Max
Danke für Deine Ausführungen.
Ich verzweifle auch immer wieder an der veralteten bis unvollständigen Doku.
Der Verweis auf Partner ist auch wenig hilfreich.

Es wäre begrüßenswert, wenn in diesem Forum ein regerer Austasuch herschen würde.
Leider steht man oft mit seiner Frage alleine.

Having said that.
Wenn oben noch 2 bis 3 Screenshots wären, würdest du das noch deutlicher machen ;-)
Ich tat mir schwer bei der Lektüre (was soll z. B. das CRM Dashboard sein?)

Mic
Hallo Michael,


wenn du mir einmal sagst, wie ich meinen  Beitrag nachträglich editieren kann werde ich ihn bei gegebener Zeit  nochmal überarbeiten und Screenshots hinzufügen.
Mit dem Dashboard  ist die KanBan im CRM gemeint, welche allerdings durch Zugriffssperrung  als Dashboard (Anzeigetafel) genutzt werden soll, da alle die meisten  Stati Updates durch den automatisierten Workflow vollzogen werden.

Danke für dein Feedback !
Geändert: Maximilian Grieß - 22.08.2019 20:33:15
Seiten: 1
5.000.000+
Organisationen
nutzen Bitrix24