Wie du sicherstellst, dass KI-Coding-Agenten aktuelle Flow Best Practices berücksichtigen

Zuletzt geprüft: 18. September 2026

KI-Coding-Agenten greifen beim Erstellen von Salesforce-Flows häufig auf veraltete Bauweisen zurück. Ihr Trainingswissen hat einen Stichtag und im öffentlichen Material sind ältere Lösungen deutlich häufiger dokumentiert als neue Flow-Funktionen. Das Ergebnis kann technisch funktionieren und trotzdem so aussehen, als wäre es vor mehreren Releases entstanden.

Ein neueres Modell allein löst das nicht. Verlässlicher sind dokumentierte Vorgaben zu aktuellen Flow-Elementen und klare Hinweise, welche bestehenden Flows in der Org als Vorlage dienen dürfen.

Warum alte Muster überwiegen

Ein Modell lernt aus Daten, die bei seiner Veröffentlichung bereits Monate alt sein können. Salesforce bringt dagegen drei Releases pro Jahr heraus. Neue Flow-Funktionen können deshalb fehlen, selbst wenn das Modell erst vor Kurzem erschienen ist.

Entscheidend ist, welche Quellen im Netz verfügbar sind. Ältere Tutorials, Forenantworten und Blogbeiträge fließen auch weiterhin in die Antworten ein, auch wenn Salesforce längst ein neues Flow-Element veröffentlicht hat. Zu einer zehn Jahre alten Flow-Funktion gibt es daher viel mehr Beispiele als zu einer Funktion aus dem letzten Release. Ein Modell greift entsprechend oft auf die häufiger dokumentierte Variante zurück.

Eine veraltete Antwort kann trotzdem sehr überzeugend klingen. Für die gewählte Bauweise findet das Modell zahlreiche Beispiele, auch wenn Salesforce inzwischen eine bessere Lösung anbietet.

Eine Möglichkeit, dies zu umgehen, ist den Agenten anzuweisen, dass er nur aktuelle Flow-Elemente verwenden und vorher im Web dazu recherchieren soll. Dann fällt dieselbe Arbeit jedoch bei jeder Aufgabe erneut an. Je nach Modell und Suchanbindung können aktuelle Quellen Vorrang erhalten. Unter Umständen kann die Recherche jedoch trotzdem bei älteren Tutorials, die schon das Trainingsmaterial prägen, landen. Da sich die Trefferlisten stetig verändern, entsteht so kein allgemeingültig geprüfter Wissensstand.

Beispiele für Flow-Bauweisen aus altem Material

Ohne klare Vorgaben greift ein Agent häufig zu denselben Bauweisen. Besonders folgenreich sind Datensätze, die innerhalb einer Schleife erstellt oder aktualisiert werden. Mit wenigen Test-Datensätzen läuft der Flow, bei größeren Datenmengen erreicht er jedoch schnell die Governor Limits.

Andere veraltete Bauweisen fallen weniger auf. Ein Flow aktualisiert etwa den auslösenden Datensatz erst nach dem Speichern, obwohl ein Before-Save-Update dasselbe Feld ohne zweiten Speichervorgang setzen könnte. Oder er erstellt eine gefilterte Sammlung innerhalb einer Schleife mit Hilfe eines Entscheidungs-Elementes, obwohl der neuere Sammlungsfilter dasselbe in einem einzigen Element erledigt.

Das Grundmuster bleibt gleich. Obwohl die Salesforce-Plattform inzwischen ein neues Element anbietet, setzt der Agent die Lösung weiterhin aus Schleifen, Entscheidungen und Zuweisungen zusammen.

Jede dieser Bauweisen kann für sich funktionieren. Sobald der fertige Flow in der Org liegt, wird er jedoch selbst zur möglichen Vorlage. Der nächste Agent liest ihn als bestehendes Muster und übernimmt dieselbe Struktur.

Flow-Vorgaben gehören ins Projekt

Ein ausführlicher Prompt vor jeder Aufgabe hilft sofort, gilt aber nur für die aktuelle Sitzung. Er verschwindet beim nächsten Start, lässt sich im Team nur schwer gemeinsam wiederholen und wird mit jeder Ergänzung schwieriger zu pflegen.

Eine mögliche Lösung ist, Arbeitsanweisungen und Referenzen versioniert im Projekt abzulegen. Wie das umgesetzt wird, hängt vom Werkzeug und den Abläufen im Team ab. Claude Code kann zum Beispiel CLAUDE.md, Rules unter .claude/rules/ und Skills aus .claude/skills/ einlesen. Wiederholbare Prüfungen lassen sich zusätzlich über Hooks ausführen. Codex liest AGENTS.md und Cursor arbeitet mit Rules unter .cursor/rules/. Diese Bausteine lassen sich je nach Projekt kombinieren.

Liegen Anweisungen, Referenzen und Prüfungen im Repository, durchlaufen sie dasselbe Review wie jede andere Änderung. Bei jedem Salesforce-Release können sie gezielt aktualisiert werden. So bleibt nachvollziehbar, mit welchem Wissensstand und welchen Prüfungen das Team arbeitet.

Eine zentrale Regel sollte das einfachste Element verlangen, das die Anforderung erfüllt. Neu allein ist kein Argument. Ohne diese Vorgabe beantwortet der Agent womöglich jede Anforderung mit dem neuesten Feature. Das Ergebnis kann dann genauso aufwendig zu warten sein wie die Schleifenkette, die es ersetzt hat.

Die Konventionen der Org lassen sich zusätzlich in der Datei festhalten, etwa ein festes Schema für API-Namen, verständliche Elementnamen und eine Beschreibung pro Element. Zuverlässig wird das erst, wenn eine deterministische Prüfung sie regelmäßig gegen die Metadaten der Org kontrolliert. Davon profitieren sowohl die Person, die den Flow später im Flow Builder öffnet, als auch der nächste Agent, der die Org ausliest.

Gegen die Ziel-Org prüfen

Wenn die Verfügbarkeit einer Funktion das Design beeinflusst, muss der Agent sie gegen die API-Version der Ziel-Org und die offiziellen Release Notes prüfen. Auf sein Trainingswissen sollte er sich dabei nicht verlassen.

Bei Funktionen, die Salesforce nicht mehr weiterentwickelt, kann eine kurze Kontextregel der erste Schritt sein. So lässt Salesforce beispielsweise schon länger keine neuen Workflow-Regeln und keine neuen Prozesse im Prozessgenerator mehr zu. Der Support für beide endete am 31. Dezember 2025. Bestehende Prozesse laufen weiter und lassen sich weiterhin aktivieren, deaktivieren und bearbeiten. Fehler werden von Salesforce jedoch nicht mehr behoben.

Die Anweisung "keine neuen Workflow-Regeln, keine neuen Prozesse im Prozessgenerator" für den KI-Agenten setzt zunächst einen klaren Rahmen. Sie kann allein jedoch nicht garantieren, dass der Agent keinen solchen Entwurf liefert. Dafür braucht es einen Harness aus Kontext, Hooks und technischen Prüfungen (also die Steuerungsschicht, die ein KI-Modell umgibt). Für Aufbau und Pflege des Harness kann zum Beispiel ein Salesforce AI Engineer zuständig sein. Ein Skript kann die erzeugten Metadaten gegen die API-Version der Ziel-Org prüfen und zusätzlich Vorgaben durchsetzen, die sich nicht allein über Kontext vermitteln lassen.

Für diese Prüfung greift die Salesforce CLI auf eine autorisierte Ziel-Org zu. Ein Deployment im Prüfmodus übergibt die Flow-Metadaten an die Metadata API, ohne sie in der Org zu speichern. Salesforce meldet dabei ungültige Feldverweise, fehlende Elemente oder eine nicht unterstützte API-Version. Vorhandene Flow-Tests können im selben Durchgang mitlaufen. Bei einem regulären Deployment findet diese Validierung ebenfalls statt, bevor Salesforce die Änderungen übernimmt. Ohne Org-Zugriff kann der Agent eine genaue Bauanleitung für den Flow Builder liefern, aber kein von Salesforce geprüftes Ergebnis.

Auch deine Salesforce-Org beeinflusst die Bauweise des KI-Agenten

Vorgaben zu aktuellen Flow-Elementen allein reichen nicht, denn ein KI-Coding-Agent liest auch die Metadaten der Org, bevor er etwas schreibt.

Was er dort findet, prägt das Ergebnis. Bei drei Feldern für dieselbe Information muss er raten, welches tatsächlich gepflegt wird. Weit gefasste Berechtigungen lassen zudem offen, welche Teile der Org der Agent überhaupt verändern darf.

Besonders einflussreich sind die vorhandenen Flows. Nimmt der Agent einen davon als Vorlage, übernimmt er auch dessen Bauweise. Enthält die Org noch nicht migrierte Automatisierungen aus der Zeit vor dem Sammlungsfilter, bestätigt sie damit die inzwischen veraltete Bauweise aus seinem Trainingsmaterial. Die Wissensdatei sollte deshalb festhalten, welche Flows als Vorlage geeignet sind, welche auf der Migrationsliste stehen und wann ein Flow neu gebaut werden soll.

Auch die Trigger-Reihenfolge ist relevant. Salesforce speichert sie im Feld triggerOrder des jeweiligen Record-Triggered Flows. Ein Agent kann diesen Wert aus den abgerufenen Flow-Metadaten lesen und sollte die bestehende Reihenfolge übernehmen, anstatt selbst eine neue festzulegen. Ob sie geändert werden soll, sollte eine Entscheidung des Salesforce-Teams bleiben.

Ein neues Teammitglied erarbeitet sich diesen Kontext während der Einarbeitung. Der Agent rekonstruiert ihn dagegen bei jedem Lauf aus den Metadaten und kennt keine Entscheidungen, die das Team nicht dokumentiert hat.

Vor der Erstellung des ersten agentengestützten Flows sollte deshalb im Vorfeld der Ist-Zustand der Salesforce-Org analysiert und diese gezielt auf den Einsatz von KI vorbereitet werden. Dazu gehören ein eindeutiges Datenmodell, bekannte Überschneidungen zwischen Automatisierungen und bewusst gesetzte Zugriffsgrenzen. So kann das Team selbst festlegen, welche Strukturen und Flows der Agent als verlässliche Grundlage verwenden darf.

Was das Salesforce-Team selbst entscheiden sollte

Lege vorab fest, welche Entscheidungen dein Team selbst trifft, auch wenn KI-Coding-Agenten aktuelle Flow-Elemente und Org-Konventionen kennen. Bei dem Bau von Screen-Flows ist dies beispielsweise von besonderer Relevanz. Der Agent kann die Struktur und die vorhandenen Metadaten berücksichtigen, kennt aber nicht den Arbeitsalltag der späteren Nutzer. Ob die Feldreihenfolge zum Gespräch am Telefon passt oder eine Beschriftung im eingebetteten Kontext verständlich ist, lässt sich nur gemeinsam mit ihnen prüfen.

Auch Namensstandards, sensible Objekte und Zuständigkeiten sollte das Team vorgeben. Ob ein Beta-Feature oder eine zusätzliche Lizenz eingesetzt wird, ist ebenfalls eine klare Produktentscheidung. Die ersten Ergebnisse eines KI-Agenten sollten deshalb wie die Arbeit eines neuen Teammitglieds bewertet und jedes Mal anhand einer festen Checkliste geprüft werden.

Wo du anfängst

Wenn du KI-Coding-Agenten für Flows einsetzen willst, beginne am besten mit den folgenden zwei Schritten. Halte zuerst aktuelle Flow-Elemente und eure Org-Konventionen in versionierten Projektanweisungen fest. Kläre anschließend, welche Strukturen und bestehenden Flows in der Org als verlässliche Grundlage dienen. Ein Plattform-Assessment kann dir außerdem dabei helfen, den Ist-Zustand deiner Salesforce-Org zu analysieren und empfehlenswerte Optimierungen vor dem ersten Einsatz von KI-Agenten aufzuzeigen.