Automator

Der Automator ist deine Werkbank für Workflow-Automatisierung. Du definierst Regeln nach dem Muster „Wenn etwas passiert, dann tue etwas”: Sobald eine Entität angelegt, geändert oder gelöscht wird, kann der Automator automatisch weitere Entitäten erzeugen oder Beziehungen knüpfen — ganz ohne manuelles Zutun.

Du erreichst den Automator über die Sidebar unter Einstellungen → System & Automatisierung → Automator (/automator). Die Seite ist nur für Tenant-Admins und Platform-Admins sichtbar.

Regeln gehören immer genau einem Mandanten. Als Tenant-Admin siehst und verwaltest du ausschließlich die Regeln deines eigenen Mandanten — auch dann, wenn du eine fremde Regel-Adresse direkt aufrufst. Nur Platform-Admins arbeiten mandantenübergreifend.

Die zwei Tabs

• Regeln — hier legst du Automatisierungsregeln an, bearbeitest und (de-)aktivierst sie.
• Ausführungen — ein Protokoll: jede ausgelöste Regel landet hier mit Status, Tiefe und den konkret durchgeführten Aktionen.

Eine Regel aufbauen

Über Neue Regel öffnet sich der Editor. Eine Regel besteht aus vier Bausteinen: Auslöser, Bedingungen, Aktionen und ein paar Sicherheits-Einstellungen.

1. Auslöser (Trigger)

• Auslöser-Entitätstyp: Welcher Entitätstyp das Ereignis liefert (z.B. Person, Rolle, Wertstrom). Es werden nur Typen angeboten, deren Fachservice aktiv ist.
• Auslöser-Aktion: Welches Ereignis die Regel startet:
  • created — eine Entität wurde neu angelegt
  • updated — eine Entität wurde geändert
  • deleted — eine Entität wurde gelöscht

2. Bedingungen (optional)

Bedingungen grenzen ein, für welche Entitäten die Regel greift. Ohne Bedingung feuert die Regel bei jedem passenden Ereignis. Mit Bedingungen prüft der Automator die Daten der auslösenden Entität.

Jede Bedingung besteht aus Feld, Operator und Wert:

• Feld: Name oder ein Feld aus dem JSON-Schema des Typs (z.B. descJsonb.abteilung).
• Operator — was die Bedingungen genau bedeuten:

Operator	Bedeutung	Beispiel (Wert „Eng”)
equals	exakt gleich	trifft auf „Eng” zu, nicht auf „Engineering”
notEquals	ungleich	trifft auf alles außer „Eng” zu
contains	enthält	trifft auf „Engineering”, „Top-Eng” zu
startsWith	beginnt mit	trifft auf „Engineering” zu
endsWith	endet mit	trifft auf „Backend-Eng” zu

• Wert: der Vergleichswert.

Wichtig: Mehrere Bedingungen innerhalb einer Gruppe sind UND-verknüpft — es müssen alle zutreffen. Der Vergleich ist nicht Groß-/Kleinschreibung-sensitiv („Eng” = „eng”). Bei deleted-Ereignissen werden Bedingungen übersprungen, weil die Entitätsdaten dann nicht mehr verfügbar sind.

Mehrere Bedingungsgruppen (ODER-Verknüpfung)

Über „ODER-Gruppe hinzufügen” legst du eine zweite Bedingungsgruppe an: die Regel feuert, wenn die auslösende Entität eine der beiden Gruppen vollständig erfüllt (Bedingungen innerhalb einer Gruppe bleiben UND-verknüpft, wie oben). Mit nur einer Gruppe sieht der Editor genauso aus wie bisher — die Gruppierung ist rein optional und wird erst sichtbar, sobald du eine zweite Gruppe hinzufügst.

Beispiel: „Abteilung ist Engineering oder Sales” → Gruppe 1: descJsonb.abteilung equals Engineering; Gruppe 2: descJsonb.abteilung equals Sales.

Advanced Mode: Bedingungen als JSON

Das Formular oben deckt UND-verknüpfte Bedingungen mit den 5 Operatoren equals/notEquals/contains/startsWith/endsWith ab — für die meisten Regeln genug. Wer im Experten-Modus arbeitet (Umschalter oben rechts in der Kopfzeile bzw. Tastenkürzel M), sieht neben den Bedingungen zusätzlich den Button „Als JSON bearbeiten”. Er öffnet einen Editor für den rohen Bedingungs-Baum mit zwei zusätzlichen Fähigkeiten:

• ODER/NICHT-Verknüpfung statt nur UND: { "or": [ {...}, {...} ] }, { "not": {...} }, beliebig verschachtelt.
• Mehr Operatoren: zusätzlich zu den 5 aus dem Formular auch gt/gte/lt/lte (Zahlenvergleich), exists/notExists (Feld vorhanden/leer) und in/notIn (Mitgliedschaft in einer Werteliste).

Beispiel — „Abteilung ist Engineering oder Sales, und die FTE-Zahl liegt über 0,5”:

{
  "and": [
    { "or": [
      { "field": "descJsonb.abteilung", "operator": "eq", "value": "Engineering" },
      { "field": "descJsonb.abteilung", "operator": "eq", "value": "Sales" }
    ]},
    { "field": "descJsonb.fte", "operator": "gt", "value": 0.5 }
  ]
}

Der Editor validiert live und markiert ungültiges JSON oder unbekannte Operatoren direkt unter dem Feld — Speichern ist erst möglich, wenn der Baum gültig ist. Der Button „Zurück zur Formularansicht” ist nur aktiv, wenn sich der aktuelle Baum verlustfrei als flache UND-Liste darstellen lässt; enthält er ODER/Verschachtelung, bleibt er deaktiviert (mit Hinweistext) — so geht beim Umschalten nie etwas still verloren. Eine Regel, die per Assistent oder MCP bereits mit einem solchen Baum angelegt wurde, öffnet sich beim Bearbeiten automatisch im JSON-Modus, unabhängig vom eigenen View-Mode.

3. Aktionen

Aktionen sind das Dann der Regel. Du kannst beliebig viele hinzufügen; sie laufen der Reihe nach. Zwei Aktionstypen stehen zur Verfügung:

• Entität erstellen (create_entity): legt eine neue Entität im Ziel-Typ an. Du gibst den Ziel-Entitätstyp und die Daten als JSON an, z.B. { "name": "Neues Onboarding" }.

  Pflichtfelder gelten auch hier: Enthalten die Daten ein Pflichtfeld des Ziel-Typs nicht (siehe JSON-Schema für Entitätstypen), bleibt der Entwurf stehen und die Ausführung wird als teilweise fehlgeschlagen protokolliert. Der Ausführungsverlauf nennt den Grund — dort nachsehen, wenn eine Regel „lief”, aber nichts entstanden ist.

• Beziehung erstellen (create_relationship): verknüpft die auslösende mit einer (gerade erzeugten) Entität. Du gibst an:
  • Beziehungstyp: der Code des Beziehungstyps, z.B. EXECUTES.
  • Richtung:
    • Auslöser → Erstellt (trigger_to_created): die Beziehung zeigt von der auslösenden zur neu erzeugten Entität.
    • Erstellt → Auslöser (created_to_trigger): umgekehrt.

Eine create_relationship-Aktion verknüpft mit der Entität aus der vorherigen create_entity-Aktion derselben Regel. Kombiniere beide also typischerweise als Paar.

Wie die Entität entsteht — und wer sie freigibt Eine create_entity-Aktion legt die Entität über denselben Weg an wie du selbst: sie erzeugt einen Entwurf und gibt ihn automatisch frei. Der Freigabemodus des Entitätstyps greift dabei nicht — die Automatisierung handelt als System und veröffentlicht sofort. Wenn eine Neuanlage bewusst durch die Freigabe laufen soll, gehört sie nicht in eine Regel, sondern bleibt manueller Entwurf. Der Beziehungstyp in create_relationship wird über seinen Namen aufgelöst; er muss in diesem Mandanten existieren, sonst meldet die Ausführung partial_failure mit „Unknown relationship type”.

4. Sicherheit & Status

• Max. Tiefe (1–10): begrenzt Automatisierungs-Ketten. Wenn eine Aktion ein Ereignis auslöst, das eine weitere Regel startet, zählt der Automator die Tiefe hoch. Bei Erreichen der Grenze stoppt die Kette. So werden Endlosschleifen verhindert. Plattformweit ist bei 10 immer Schluss, selbst wenn du höher einträgst.
• Aktiv: Nur aktive Regeln feuern. Über den Schalter in der Liste kannst du eine Regel jederzeit pausieren, ohne sie zu löschen.

Beispiel: Onboarding automatisch anstoßen

„Wenn eine Person in der Abteilung Engineering neu angelegt wird, verknüpfe sie automatisch über EXECUTES mit der Standard-Rolle.”

• Auslöser-Entitätstyp: Person
• Auslöser-Aktion: created
• Bedingung: descJsonb.abteilung equals Engineering
• Aktion: Beziehung erstellen → Beziehungstyp EXECUTES, Richtung Auslöser → Erstellt
• Max. Tiefe: 3

Ausführungen lesen

Im Tab Ausführungen siehst du jede ausgelöste Regel. Aufklappen zeigt Details:

• Status: completed (alles ok), partial_failure (einzelne Aktionen schlugen fehl), failed, running, pending.
• Tiefe: Position in der Automatisierungs-Kette (0 = direkt ausgelöst).
• Chain-ID: gruppiert alle Ausführungen einer Kette — nützlich, um nachzuvollziehen, was eine erste Aktion alles ausgelöst hat.
• Durchgeführte Aktionen: je Aktion Typ, Ziel-Typ und das Ergebnis (bzw. die Fehlermeldung).

Wartungstipps

• Erst mit Bedingungen einkränken: Eine Regel ohne Bedingungen feuert bei jedem Ereignis des Typs — leicht zu viel.
• Niedrige Tiefe wählen: Für die meisten Fälle reicht maxDepth 2–3. Höhere Werte nur, wenn Ketten beabsichtigt sind.
• Nach Anlegen testen: Lege eine passende Testentität an und prüfe im Tab Ausführungen, ob die Regel wie erwartet greift.
• Pausieren statt löschen: Über den Aktiv-Schalter kannst du eine Regel vorübergehend stilllegen.

Per Assistent anlegen (rAlph)

Statt das Formular auszufüllen, kannst du eine Automatisierung in eigenen Worten beschreiben: Tippe im Assistenten /automator und dann z.B. „Immer wenn ein Kreis erstellt wird, lege die LeadLink-Rolle an und verknüpfe sie mit dem Kreis.” rAlph baut daraus einen Regel-Vorschlag und zeigt ihn als Karte im Chat — mit Auslöser, Aktionen und Verknüpfung. Erst dein Klick auf „Regel anlegen” erstellt die Regel (rAlph legt nichts von selbst an).

In den Feldwerten erzeugter Entitäten kannst du Platzhalter nutzen, die Werte der Auslöser-Entität übernehmen — z.B. der Rollenname LeadLink von {{trigger.name}} übernimmt den Namen des erstellten Kreises. Der Befehl steht nur Nutzern mit Admin-Rechten zur Verfügung.

rAlph versteht dabei auch Formulierungen mit „oder” („wenn die Abteilung Engineering oder Sales ist”) und baut daraus direkt einen ODER-verknüpften Bedingungs-Baum — im Regel-Editor erscheint eine solche Regel dann automatisch im JSON-Modus.

Verwandt

• rAlph – Slash-Befehle (/help, /report, /drafts) — Slash-Befehle des Assistenten
• Validator — prüft Daten bevor sie freigegeben werden (statt danach zu reagieren)
• Aggregator — wertet die entstandenen Daten in Reports aus
• Beziehungstypen — die Beziehungstypen, die du in Aktionen nutzt
• JSON-Schema für Entitätstypen — woher die Feldnamen für Bedingungen kommen