Automationen als Code: die Automatisierungs-API

In Makler-CRMs sind Automationen üblicherweise Konfiguration. Jemand klickt sie in der Oberfläche zusammen, sie laufen, und wenn etwas nicht stimmt, klickt jemand sie um. Was vorher galt, weiß danach niemand mehr.

In propgen sind Automationen ab sofort etwas anderes: Artefakte mit einem Lebenszyklus. Sie lassen sich auslesen, prüfen, gegen echte Daten testen, freigeben und zurückrollen — vollständig über die öffentliche API.

name: Stille Objekte melden
trigger:
  type: schedule
  at: "07:00"
when:
  field: objekt.letzte_besichtigung
  older_than_days: 40
then:
  - action: task.create
    assignee: objekt.betreuer

Der Weg einer Automation

1. 1
   Lesen

   Der Automatisierungsbestand lässt sich über alle Automationen hinweg auflisten: welche existieren, welchen Status sie haben, wie ihre Pläne aussehen.
2. 2
   Validieren

   Ein Plan lässt sich auf Konsistenz prüfen, bevor er irgendwo landet. Referenztypen und die dazu passenden Werte in Deiner Konfiguration sind über die API auffindbar — ein Plan kann also gegen den tatsächlichen Stand geprüft werden.
3. 3
   Rücktesten

   Ein Plan lässt sich gegen echte Datensätze durchspielen. Du siehst, welche Datensätze die Bedingungen erfüllt hätten und was passiert wäre — ohne dass eine einzige Aktion ausgeführt wird.
4. 4
   Entwerfen

   Schreibzugriff über die API erzeugt zunächst nur inaktive Entwürfe. Eine per API angelegte Automation wirkt nicht, bis sie aktiviert wird — und Aktivieren ist ein eigenes Recht, das separat vergeben wird.
5. 5
   Deployen

   Deployments haben eine eigene Historie: Was wann von wem ausgerollt wurde, ist nachvollziehbar. Ob ein Deployment direkt produktiv wirkt oder auf eine Freigabe wartet, bestimmt die Richtlinie Deiner propgen-Umgebung.
6. 6
   Zurückrollen

   Ein Deployment lässt sich zurücknehmen. Der Zustand davor ist kein Rekonstruktionsprojekt, sondern ein Vorgang. Was gar nicht mehr gebraucht wird, lässt sich über dieselbe Schnittstelle löschen.

Ergänzend: Automationen lassen sich über einen externen Schlüssel per Upsert pflegen, Pläne gegeneinander vergleichen und exportieren. Das Plan-Schema ist maschinenlesbar — Automationen können damit in einem Repository liegen wie jeder andere Code.

Woran eine Automation hängt — und was sie tut

Mit der Schnittstelle ist auch der Baukasten gewachsen. Welche Auslöser, Bedingungen und Aktionen die aktuelle Schema-Version trägt, gibt der Capabilities-Endpunkt maschinenlesbar aus — hier die Erweiterungen dieser Runde:

• Neue Auslöser — Zeitplan und Webhook, dazu Aufgaben, Notizen, Buchungen und der Datenraum. Damit startet eine Automation nicht mehr nur, wenn sich ein Datensatz ändert, sondern auch zu einem festen Zeitpunkt, auf Zuruf von außen — oder wenn im Datenraum etwas passiert: Unterlagen angesehen oder heruntergeladen, eine Datei hochgeladen, eine Rückmeldung abgegeben, eine Unterschrift geleistet.
• Neue Aktionen — einen Deal aktualisieren und eine E-Mail archivieren. Beides Schritte, die bisher am Ende einer Automation von Hand nachgezogen werden mussten.
• Schema-basierte Bedingungsfelder — die Bedingungen einer Automation greifen auf dieselbe Felddefinition zu wie das Formular. Ein Feld, das es nicht gibt, lässt sich damit gar nicht erst in eine Bedingung schreiben. Datenraum-Auslöser lassen sich zusätzlich auf einzelne Datenraum-Vorlagen einschränken — die Automation greift dann nur für die Räume, die aus dieser Vorlage entstanden sind.

Rechte folgen der Wirkung

Die Rechtestruktur ist nicht nach Funktionsbereichen geschnitten, sondern nach der Frage: Wirkt diese Aktion produktiv?

Vergibst Du nur die folgenlosen Rechte plus Entwürfe, bekommt ein Integrationspartner genau das, was er für seine Arbeit braucht — Pläne lesen, validieren, testen, Entwürfe schreiben —, ohne dass er im laufenden Betrieb etwas auslösen kann. Unabhängig von den Rechten gilt eine Grenze in die andere Richtung: Was in der Oberfläche aktiviert wurde, bleibt für die API unantastbar. Ändern, deaktivieren oder löschen kann sie nur, was sie selbst aktiviert hat — Deine von Hand gebauten Automationen kann eine Integration also nicht umlegen. Wie sich Rechte im Team darüber hinaus schneiden lassen, steht in Rollen und Rechte.

Der Schritt in den Produktivbetrieb

• Schreiben und Aktivieren sind getrennt — Schreibzugriff erzeugt inaktive Entwürfe. Aktivieren ist ein eigenes Recht: Wer es nicht hat, kann nichts scharf schalten, egal wie viel er sonst darf.
• Die Freigabe folgt Deiner Richtlinie — ob ein Deployment direkt produktiv wirkt oder auf eine Freigabe wartet, ist eine Einstellung in Deiner propgen-Umgebung. Wer den Vier-Augen-Schritt will, hinterlegt ihn dort einmal und er gilt für jedes Deployment.
• Der KI-Agent prüft, er löst nicht aus — er kann Automationen erklären, validieren und durchspielen, ohne dass dabei etwas passiert.

Eine Automation kann damit per API entstehen, geprüft und getestet werden — was danach live geht, behältst Du über zwei Stellschrauben in der Hand: welche Rechte ein Schlüssel bekommt und welche Freigaberichtlinie gilt. Wer Automationen von außen bauen lässt, aber selbst entscheiden will, was scharf geht, vergibt die produktiven Rechte nicht. Ähnlich lässt sich der Rahmen für die eigenen KI-Agenten setzen.

Betrieb und Beobachtbarkeit

• Läufe und Kennzahlen über die API — Automatisierungsläufe sind lesbar, mit Laufzeiten und redigierten Diagnosen; aggregierte Kennzahlen propgen-weit abrufbar.
• Lifecycle-Webhooks — Lauf-Ergebnisse werden an angebundene Systeme gemeldet, statt dort abgefragt werden zu müssen.
• Eingreifen, wenn es nötig ist — aktive API-Automationen manuell starten, wartende Läufe gezielt abbrechen. Jeder wirksame Aufruf verlangt dabei einen Idempotenzschlüssel: Wird derselbe Aufruf wiederholt, liefert die Schnittstelle das Ergebnis des ersten zurück, statt ein zweites Mal zu handeln.

Für wen das gebaut ist

• Häuser mit eigener IT oder festem Integrationspartner — die Prozesse nicht in einer Oberfläche pflegen wollen, sondern versioniert, geprüft und mit einem Weg zurück.

Wer Automationen lieber klickt, klickt sie weiter: Der Workflow Manager bleibt unverändert. Die API ersetzt die Oberfläche nicht — sie beantwortet die Frage, was passiert, wenn ein Prozess über Jahre und über mehrere Beteiligte hinweg gepflegt werden muss.

Verfügbarkeit

Die Automatisierungs-API steht ab sofort zur Verfügung. Die Rechte werden wie gewohnt je API-Schlüssel vergeben — für einen Integrationspartner empfiehlt sich der Einstieg mit den folgenlosen Rechten plus Entwürfen.

Verwandte Releases: die Public API und Webhooks als Grundlage, Formulare per API für Masken und Felder, der Workflow Manager als Oberfläche und Rollen und Rechte für die Vergabe im Team.

Mehr zu allen propgen-Funktionen findest Du im Funktionsüberblick.