Universelle Listen sind tabellarische Register innerhalb von Bitrix24: Ausgabenanträge, Verzeichnisse von Geschäftspartnern, Listen von Verträgen und Zugängen. Ihre wichtigste Eigenschaft – auf den Listenelementen laufen vollwertige Geschäftsprozesse aus dem Designer: Start beim Erstellen eines Elements, beim Ändern oder manuell. Wir klären, für welche Daten eine Liste die richtige Wahl ist, wie ein typischer Prozess „Ausgabenantrag“ aufgebaut ist, was man mit JSON von externen Systemen macht und in welchen Fällen man statt einer Liste besser gleich einen Smart-Prozess anlegt.

Was sind universelle Listen und wofür eignen sie sich?

Eine Liste ist eine Tabelle mit konfigurierbaren Feldern: Text, Zahl, Datum, Verknüpfung zu einem Mitarbeiter, Datei, Auswahlliste. Jedes Element ist eine Zeile des Registers. Die Stärke der Listen sind Daten, die keine Verkaufspipeline brauchen: interne Anträge (Ausgabe, Urlaub, Systemzugang), Verzeichnisse (Tarife, Filialen, Standardpositionen), Journale (Verträge, Vollmachten, Vorfälle). Listen leben getrennt vom CRM, mit eigenen Zugriffsrechten: wer das Register sieht, wer Elemente hinzufügt, wer fremde ändert. Praktisches Auswahlkriterium: Wenn Daten „geführt und genehmigt“ werden müssen – passt eine Liste; wenn Karten „über Phasen bewegt“ werden müssen – schauen Sie in Richtung Smart-Prozesse, zu dieser Grenze unten mehr.

Wie aktiviert man Geschäftsprozesse auf einer Liste?

In den Einstellungen der Liste wird die Unterstützung für Geschäftsprozesse aktiviert – danach erhält die Liste einen eigenen Satz an Vorlagen im Workflow-Designer. Eine Vorlage wird an ein Ereignis gebunden: Autostart beim Hinzufügen eines Elements, Autostart beim Ändern oder manueller Start aus dem Element. Die Felder des Elements stehen der Vorlage als Dokumentfelder zur Verfügung – man kann sie in Bedingungen auslesen, in Benachrichtigungen einsetzen und mit der Aktion zur Dokumentänderung überschreiben. Typische Kombination für ein Antragsregister: Autostart beim Hinzufügen – der Prozess prüft die Daten, weist einen Genehmiger zu und ändert je nach Ergebnis das Statusfeld des Elements. Wie der Designer, Variablen und Bedingungen überhaupt aufgebaut sind, lesen Sie im Überblick zu Geschäftsprozessen.

Wie ist ein typischer Prozess aufgebaut: der Ausgabenantrag?

Ein Mitarbeiter fügt ein Element hinzu: Betrag, Ausgabenposten, Kommentar. Der Prozess startet automatisch und entscheidet zuerst, welche Route er nimmt. Die Standardaktion „Bedingung“ vergleicht einen einzigen Wert, und schon bei zwei bis drei Kriterien verwandelt sich die Vorlage in eine Treppe verschachtelter Zweige. Der Roboter „Zusammengesetzte Bedingung (AND / OR / NOT)“ fasst die Prüfung in einem Schritt zusammen: bis zu vier Paare „Wert – Operator – Wert“ mit der Logik AND oder OR, und für verzweigte Regelwerke ein JSON-Modus mit beliebiger Verschachtelung der Gruppen and, or und not. Er liefert ein einziges Kennzeichen Y/N: Betrag innerhalb des Limits UND Posten ist Standard – genehmigt der Abteilungsleiter; andernfalls – der Finanzdirektor. Das Ergebnis der Phase schreibt der Prozess in das Statusfeld des Elements, und das Register bleibt ehrlich.

Wie verarbeitet man JSON, das in eine Liste gelangt?

Listen dienen oft als Puffer für externe Systeme: Ein Antrag trifft von der Website ein, ein Status aus dem Buchhaltungssystem, und im Textfeld des Elements landet das gesamte JSON. Den „rohen“ String durch die Prozessschritte zu schleppen ist nicht nötig – der Roboter „Wert aus JSON nach Pfad extrahieren“ zerlegt den JSON-String und liefert den Wert nach Pfad über den Punkt: zum Beispiel data.user.email oder items.0.name. Strings werden unverändert zurückgegeben, Objekte und Arrays als JSON zur weiteren Verarbeitung, dazu das Kennzeichen „Pfad gefunden“ (Y/N) – darüber leitet der Prozess fehlerhafte Daten in einen separaten Zweig, statt stillschweigend mit Leere fortzufahren. Wie man JSON überhaupt von außen in Bitrix24 bringt, steht im Artikel über Webhooks.

Wann ist statt einer Liste ein Smart-Prozess besser?

Eine Liste ist eine Tabelle: Sie hat kein Kanban, keine Phasen und keine Roboter auf Phasen, die Automatisierung lebt nur in den Vorlagen des Designers. Solange ein Antrag in die Logik „hinzugefügt – genehmigt – geschlossen“ passt, reicht das aus. Anzeichen, dass ein Register über eine Liste hinausgewachsen ist: Das Team braucht ein Kanban nach Phasen, man wünscht sich Roboter und Trigger wie in einer Pipeline, die Elemente müssen mit Deals, Kontakten und Unternehmen verknüpft werden. Dann legen Sie einen Smart-Prozess an – eine vollwertige CRM-Entität mit Phasen, Robotern und Verknüpfungen; einen ausführlichen Vergleich gibt es in der Analyse der Smart-Prozesse. Praktische Regel: Verzeichnisse und Journale – eine Liste; ein Strom gleichartiger Karten, den Menschen über Phasen bewegen – ein Smart-Prozess.

Fazit

Listen decken Register ab: Anträge, Verzeichnisse, Journale – mit Zugriffsrechten und Geschäftsprozessen auf den Elementen. Die Route eines Antrags wird im Workflow-Designer zusammengebaut: Verzweigungen nach Betrag und Posten – der Roboter „Zusammengesetzte Bedingung“, Daten von externen Systemen – „Wert aus JSON nach Pfad extrahieren“. Sobald ein Register Phasen und Kanban braucht – steigen Sie auf einen Smart-Prozess um, die Logikvorlagen lassen sich mit denselben Bausteinen übertragen. Roboter für beide Fälle finden Sie im Roboteka-Katalog, die Installation aus dem Bitrix24.Market ist kostenlos. Es fehlt die passende Aktion – beschreiben Sie die Aufgabe, wir bauen den Roboter kostenlos.