Salesforce AI Engineer: Löst diese Rolle Salesforce Admins und Developer ab?

Zuletzt geprüft: 28. September 2026

Während Salesforce Administratoren traditionell bisher in enger Zusammenarbeit mit den Fachabteilungen viele Anforderungen direkt über Konfiguration und Automatisierung in der Org umgesetzt haben, kamen Developer häufig dann ins Spiel, wenn eine Lösung über die Möglichkeiten der Konfiguration hinausging oder individuelle Entwicklung, Tests und ein kontrolliertes Deployment erforderlich waren. Mit KI-Coding-Agenten nähern sich diese Aufgabenbereiche nun einander an.

Ein KI-Agent kann beispielsweise innerhalb weniger Minuten einen Flow entwerfen. Dass der Flow technisch funktioniert, bedeutet allerdings noch nicht, dass er zur konkreten Salesforce-Org und zum darin abgebildeten Geschäftsprozess passt. Damit ein Agent zuverlässig arbeiten kann, muss das Salesforce-Team vorher festlegen, welche fachlichen Regeln für ihn gelten, welche Werkzeuge er verwenden darf und woran das Team eine korrekte Änderung erkennt.

Genau an dieser Schnittstelle entsteht eine neue Verantwortung. Pariveo verwendet dafür in diesem Beitrag die Rollenbezeichnung „Salesforce AI Engineer“. Gemeint ist damit nicht einfach ein Developer, der KI-Tools verwendet. Gemeint ist die Verantwortung für einen Arbeitsablauf, in dem fachliches Org-Wissen, Administration, Entwicklung und KI-Coding-Agenten zusammenwirken.

Ein KI-Agent kennt die Org nicht so, wie ihr Team sie kennt

Ein Beispiel: Nach dem Abschluss einer Opportunity soll automatisch eine Übergabeaufgabe erstellt werden. Der Coding-Agent liefert dafür einen Flow. Auf den ersten Blick sieht der Entwurf plausibel aus.

Der Agent hat drei Felder gefunden, die einen Übergabestatus beschreiben, und eines davon als Trigger gewählt. Eine bestehende Integration befüllt jedoch ein anderes Statusfeld. Diese Abhängigkeit lässt sich allein anhand der Feldmetadaten nicht zuverlässig erkennen.

Ob der Flow-Entwurf zur Org passt, ist damit noch ungeklärt. Jemand muss vorher festlegen, welches Feld maßgeblich ist und wie die neue Automatisierung mit der bestehenden Integration zusammenspielt.

Weitere Fragen kommen hinzu: Was soll passieren, wenn die Opportunity erneut geöffnet und später wieder abgeschlossen wird? Wer darf die erstellte Aufgabe sehen? Soll eine bereits vorhandene Aufgabe aktualisiert oder eine neue Aufgabe angelegt werden?

Solche Entscheidungen kann ein KI-Agent nicht zuverlässig aus Metadaten ableiten. Sie gehören zum fachlichen Wissen des Teams und müssen so dokumentiert sein, dass der Agent sie berücksichtigen und das Team das Ergebnis später prüfen kann.

Damit verschiebt sich die entscheidende Frage: Nicht mehr „Kann der Agent diesen Flow bauen?“, sondern „Unter welchen Bedingungen kann das Team dem Ergebnis vertrauen?“

Vom Salesforce-Wissen zum Agenten-Arbeitsplatz

Damit ein KI-Coding-Agent zuverlässig arbeiten kann, braucht er mehr als Zugriff auf den Quellcode. Er benötigt einen definierten Arbeitsrahmen, der technische Informationen, fachliche Entscheidungen, Werkzeuge und Prüfungen miteinander verbindet.

Wir nennen diesen Arbeitsrahmen Harness.

Mit Harness meinen wir die Arbeitsumgebung rund um den Coding-Agenten. Darin hält das Team fest, welcher Kontext gilt, welche Werkzeuge zur Verfügung stehen, auf welche Org und Daten zugegriffen werden darf und welche Prüfungen eine Änderung durchlaufen muss.

Der Harness ist damit mehr als eine technische Konfiguration. Er übersetzt das Wissen des Salesforce-Teams in Regeln und Nachweise, mit denen ein KI-Coding-Agent arbeiten kann.

1. Kontext: Was muss der Agent über die Org wissen?

Brauchbarer Org-Kontext für KI-Coding-Agenten verbindet die technische Struktur mit den fachlichen Entscheidungen des Teams. Für die Übergabe aus dem anfänglichen Beispiel wäre das beispielsweise eine kurze Erklärung dazu, welches Feld den relevanten Status trägt, welcher bestehende Flow als Vorlage dient und wann bereits eine Aufgabe angelegt wird.

Denn die fachliche Absicht lässt sich nicht allein aus der Org ableiten. Ein Feldname beantwortet beispielsweise nicht, ob ein altes Statusfeld noch von einer Integration genutzt wird. Ebenso wenig verrät die Org, welcher bestehende Flow als Vorlage dienen soll.

Bei der Angabe eines bestimmten Flows, der als Vorlage für einen neuen Flow dienen soll, sollte berücksichtigt werden, dass ein Agent auch dessen Bauweise übernimmt. Falls der Vorlage-Flow veraltete Flow-Muster enthält, werden diese vom Agenten übernommen. Ist die Vorlage für den neuen Übergabe-Flow noch nicht eindeutig geeignet, sollte diese Unsicherheit deshalb ausdrücklich im Arbeitsauftrag stehen.

Wir empfehlen, solche Entscheidungen in kurzen Projektanweisungen mit Verweisen auf die relevanten Felder, Flows und Testfälle festzuhalten. Zum Übergabeprozess gehören beispielsweise die betroffenen Felder, die vorhandenen Automatisierungen und die erwarteten Ergebnisse der Testfälle.

Bleibt dabei unklar, welche Automatisierungen sich überschneiden oder welches Feld tatsächlich gepflegt wird, hilft eine Bestandsaufnahme. Ein Plattform-Assessment nimmt genau diese Überschneidungen auf und ordnet die nächsten Schritte nach Priorität.

KI-Agenten entwickeln vs. mit KI-Coding-Agenten entwickeln

Dabei sollte man zwei Einsatzbereiche unterscheiden. KI-Coding-Agenten unterstützen bei der Entwicklung einer Salesforce-Anwendung. Ein Agentforce-Agent ist dagegen Teil dieser Anwendung und kann beispielsweise einen Kundenserviceprozess ausführen.

Salesforce beschreibt selbst einen Entwicklungsablauf mit Agent Skills und CLI, in dem ein Coding-Agent beim Entwerfen, Bauen, Testen und Debuggen eines Agentforce-Agenten hilft.

Die Arbeit mit beiden Agentenarten kann sich überschneiden. Wer beispielsweise eine Agentforce-Aktion in Apex entwickelt, benötigt fachliches Prozesswissen ebenso wie einen verlässlichen Entwicklungsablauf. Auch Berechtigungen, Tests und Abnahmekriterien spielen in beiden Bereichen eine wichtige Rolle.

Skills als Teil des Kontexts

Einen weiteren Baustein für die Arbeitsumgebung des Coding-Agenten liefert die Salesforce Skills Library. Das Repository enthält Skills unter anderem für Apex, Flows und die Arbeit mit Objekten und Feldern. Es folgt der offenen Agent-Skills-Spezifikation.

Salesforce weist zugleich darauf hin, dass sich die Bibliothek häufig verändert und Skills nicht dieselben Stabilitätszusagen wie allgemein verfügbare Plattform-APIs haben.

Ein Skill bündelt Anweisungen und gegebenenfalls Skripte oder Referenzen. Nach der Agent-Skills-Spezifikation lädt ein Agent die vollständigen Anweisungen bei Bedarf.

Für ein Projekt reicht es deshalb nicht, einen Skill einfach zu installieren. Das Team sollte festlegen, welche Skills geprüft wurden, welche lokalen Konventionen sie ergänzen und wie Aktualisierungen kontrolliert übernommen werden.

2. Werkzeuge und Zugriff: Was darf der Agent tatsächlich tun?

Die Werkzeugauswahl legt fest, welche Operationen ein Agent anfragen kann. Dafür muss ein Team nicht zwingend eine komplett neue Entwicklungsumgebung einführen. Ein Coding-Agent arbeitet über dieselben Werkzeuge wie die Entwicklung, also Salesforce CLI, Git und die vorhandene Deployment-Strecke.

Gängige Coding-Agenten lassen sich pro Kommando freigeben oder sperren. Ihre Hooks greifen vor der Ausführung und können ein Kommando anhalten oder ablehnen.

So kann beispielsweise der Abruf von Metadaten oder eine Validierung ohne Speichern ohne Rückfrage erlaubt werden. Ein Deployment in eine produktive Org sollte hingegen eine ausdrückliche Freigabe verlangen.

Fehlen dem verwendeten Benutzer die dafür nötigen Berechtigungen, lässt die Org das Deployment auch über die Metadata API nicht zu.

Die wichtigste Zugriffsschranke ist jedoch nicht das einzelne Tool, sondern der Benutzer, über den der Agent authentifiziert ist. Ein eigener Benutzer in der Sandbox ohne Zugriff auf produktive Daten begrenzt die Möglichkeiten sämtlicher Werkzeuge gleichzeitig.

Für die Automatisierung aus unserem anfänglichen Beispiel empfehlen wir zunächst einen klar abgegrenzten Entwicklungsumfang. Der Agent darf die benötigten Metadaten lesen, einen Entwurf im Repository erstellen und ihn gegen eine Sandbox prüfen. Schreibzugriff auf produktive Geschäftsdaten ist für diesen Arbeitsauftrag nicht erforderlich.

Wenn die CLI nicht ausreicht

Wo ein Agent mehr braucht als die CLI, kommen Salesforce Hosted MCP Servers infrage. Sie machen Org-Daten und Automatisierungen für kompatible KI-Clients zugänglich, einschließlich eigener Werkzeuge für Apex und Flows.

Der OAuth-Scope mcp_api betrifft dabei den Zugang zu den MCP-Servern und gilt laut Salesforce als Alternative zum breiteren Platform-API-Scope. Welche Operationen möglich sind, hängt zusätzlich von der Werkzeugfreigabe und den Benutzerberechtigungen ab.

Eine Beschreibung innerhalb eines Tools ist dabei keine verbindliche Zugriffskontrolle, wie Salesforce in seinen MCP-Sicherheitshinweisen erläutert.

Bei eigenen Apex-Werkzeugen gilt die Grenze über den Benutzer nur eingeschränkt, weil der Ausführungskontext dessen Rechte nicht automatisch übernimmt. Die konkrete Implementierung sollte deshalb mit den vorgesehenen Benutzerrechten geprüft werden, bevor das Team sie als Werkzeug freigibt.

3. Abnahme: Woran erkennen wir eine passende Änderung?

Der dritte Teil des Harnesses beantwortet die entscheidende Frage aus dem Anfang: Woran erkennt das Team, dass der Agent nicht nur etwas gebaut hat, sondern die richtige Änderung?

Eine Abnahme sollte zeigen, was geändert wurde und welche Überprüfungen tatsächlich gelaufen sind. Für den Übergabe-Flow aus dem anfänglichen Beispiel umfasst unser Vorgehen den Änderungsdiff sowie Testfälle für die erste Übergabe und den erneuten Abschluss der Opportunity.

Damit lässt sich die Umsetzung an der ursprünglichen Anforderung messen und nicht nur auf technische Gültigkeit prüfen.

Die Salesforce CLI unterstützt mit sf project deploy start --dry-run eine Deployment-Validierung, ohne die Änderungen in der Org zu speichern. Welche Apex-Tests laufen, hängt vom gewählten Testlevel ab. Die CLI-Dokumentation empfiehlt für eine Sandbox-Validierung mit Tests ausdrücklich --test-level RunLocalTests.

Das Team sollte Ziel-Org, Umfang und Testergebnisse festhalten, damit auch später nachvollziehbar bleibt, was tatsächlich validiert wurde.

Allerdings lässt sich nicht jedes Kriterium über diesen Weg überprüfen. Benennungskonventionen können beispielsweise über den Salesforce Code Analyzer geprüft werden, erweiterbar über PMD, ESLint oder Regex.

Ob die Aufgabe erst beim endgültigen Abschluss der Opportunity erstellt wird und nicht schon bei einer Statusänderung davor, zeigt dagegen nur ein Test des fachlichen Verhaltens.

Deshalb gilt für den Harness: Jedes Abnahmekriterium braucht einen passenden Nachweis.

Was daraus für Salesforce Admins und Developer folgt

Bis hierhin zeigt sich, warum die Rolle des Salesforce AI Engineers nicht einfach eine neue Variante des Developers ist. Sie verbindet Verantwortlichkeiten, die bisher stärker auf unterschiedliche Rollen verteilt waren.

Salesforce Administratoren und Developer hatten bisher unterschiedliche Schwerpunkte in der technischen Umsetzung. Bei agentengestützten Änderungen müssen beide fachliche Anforderungen, technische Umsetzung und Prüfungen stärker miteinander verbinden.

Salesforce Administratoren bringen Prozesswissen ein. Developer bringen Entwicklungspraktiken ein. Beides wird für den Einsatz von KI-Coding-Agenten relevant.

Die zentrale Veränderung besteht damit weniger in einer neuen Stellenbezeichnung als in der Verbindung dieser Kompetenzen.

Der Weg aus der Salesforce Administration

Aus der Salesforce Administration kommt das Wissen, das dem Agenten fehlt: Warum existiert ein Feld? Welcher Prozess wird tatsächlich gelebt? Welche Anforderungen haben die Fachabteilungen?

Der nächste Schritt führt von dort stärker in Richtung Software-Architektur und prüfbarer Anforderungen. Was passiert, wenn derselbe Ablauf zweimal läuft? Wovon hängt diese Änderung ab? Woran erkennt das Team, dass sie sich nicht mehr wie vorgesehen verhält?

Wer Prozesse entwirft, stellt diese Fragen inhaltlich längst. Versionsverwaltung, Testfälle und Review-Konventionen übersetzen dieses Wissen zusätzlich in eine Form, mit der ein Coding-Agent arbeiten kann.

Der Weg aus der Salesforce-Entwicklung

Aus der Salesforce-Entwicklung kommt die Erfahrung, eine Änderung belegbar zu machen. Reviews, automatisierte Prüfungen und ein geregeltes Deployment in die produktive Org gehören dazu.

Der nächste Schritt führt hier stärker in Richtung Fachlichkeit. Ein Agent kann Code liefern, der alle automatisierten Überprüfungen durchläuft und trotzdem den falschen Prozess abbildet. Wer die fachliche Absicht hinter einer Änderung versteht, kann diesen Unterschied erkennen.

Die gemeinsame Verantwortung

Beide Wege führen zu einer gemeinsamen Verantwortung. Wer Referenz-Flows und fachliche Testfälle pflegt, arbeitet am selben Harness wie die Person, die automatisierte Prüfungen einrichtet und Apex-Änderungen begutachtet.

Administratoren lernen dabei, Anforderungen mit prüfbaren Akzeptanzkriterien zu formulieren. Developer lernen, den fachlichen Zweck einer Änderung nicht nur technisch umzusetzen, sondern auch zu berücksichtigen.

Ob daraus eine eigene Stelle, eine neue Spezialisierung oder eine zusätzliche Verantwortung innerhalb bestehender Rollen wird, hängt vom Arbeitsumfang und der Organisation ab. Die eigentliche Veränderung beginnt nicht mit der Stellenbezeichnung, sondern mit der Verantwortung für Kontext, Werkzeuge und Abnahme agentengestützter Änderungen.

Wie Salesforce-Teams mit KI-Coding-Agenten starten können

Als Einstieg empfehlen wir eine konkrete Änderung in einer Sandbox, für die das Team das erwartete Ergebnis beschreiben kann. Die Übergabeaufgabe aus dem anfänglichen Beispiel eignet sich dafür als überschaubares Muster.

Der erste Arbeitsablauf kann dabei bewusst klein bleiben:

1. Das Team definiert im Ticket einen festen Arbeitsumfang: betroffene Felder und Automatisierungen, Leitplanken für Änderungen, Ziel-Sandbox und die Person für die fachliche Abnahme.
2. Bereits bei der Aufnahme der Anforderung legt es prüfbare Akzeptanzkriterien fest. Für die Übergabeaufgabe aus dem Beispiel gehören dazu die erste Erstellung der Aufgabe, das Verhalten beim erneuten Abschluss der Opportunity und der Änderungsdiff.
3. Der Agent erhält nur die Werkzeuge und Zugriffe, die er für diese Aufgabe benötigt.
4. Nach der Ausführung werden Änderung, Testergebnisse und fachliche Abnahme gemeinsam betrachtet.
5. Nach jeder Aufgabe hält das Team fest, welcher Org-Kontext, welche Werkzeuggrenze oder welche Prüfung gefehlt hat, und ergänzt die Projektanweisungen, Berechtigungen und Tests.

Dieser letzte Schritt ist besonders wichtig: Der Harness sollte nicht als einmalige Konfiguration verstanden werden.

Ändert sich später dieser Beispielprozess, müssen die zugehörigen Projektanweisungen und Testfälle mitgeprüft werden. Der Org-Kontext kann sonst veralten: Der Agent würde etwa einen früheren Referenz-Flow verwenden, obwohl das Team inzwischen einen anderen Ablauf eingeführt hat.

Der Harness entwickelt sich damit gemeinsam mit dem Einsatz des Agenten. Ein anfängliches Konzept muss nicht jedes Detail vorwegnehmen. Mit jeder Alltagsaufgabe werden die Anweisungen, Zugriffe und Prüfungen genauer.

Was ist dann ein Salesforce AI Engineer?

Die Antwort auf die Ausgangsfrage lautet damit nicht einfach „ja“ oder „nein“. Die Rolle des Salesforce AI Engineers beschreibt vielmehr eine neue Verbindung bisher getrennter Verantwortlichkeiten.

Ein KI-Coding-Agent kann Code und Konfiguration schneller erzeugen. Er kennt aber nicht automatisch die fachliche Bedeutung eines Feldes, die Geschichte einer Automatisierung oder die Erwartungen der Benutzer.

Salesforce Administratoren bringen das Wissen über die Org und deren individuelle Prozesse mit. Developer steuern Entwicklungspraktiken, Reviews und Tests bei. Der Salesforce AI Engineer verbindet dieses Wissen mit einem kontrollierten Arbeitsablauf, in dem KI-Coding-Agenten sicher und nachvollziehbar eingesetzt werden können.

Dazu gehören insbesondere:

• den relevanten Org-Kontext definieren
• fachliche Anforderungen in prüfbare Kriterien übersetzen
• Werkzeuge und Zugriffe begrenzen
• geeignete Referenzen und Skills bereitstellen
• technische und fachliche Prüfungen miteinander verbinden
• Änderungen nachvollziehbar abnehmen
• den Arbeitsablauf auf Basis der Erfahrungen des Teams kontinuierlich weiterentwickeln

Damit ersetzt der Salesforce AI Engineer nicht automatisch Salesforce Admins oder Developer. Vielmehr verändert die Rolle, wie deren Wissen eingesetzt wird: Ein Teil dieses Wissens wird zum Arbeitskontext, zu den Leitplanken und zu den Prüfungen, innerhalb derer ein KI-Coding-Agent arbeiten kann.

Nächster Schritt

Wenn du KI-Coding-Agenten in deiner Salesforce-Org einsetzen möchtest, beginne nicht mit dem Agenten, sondern mit einer klar abgegrenzten Änderung. Definiere den benötigten Org-Kontext, begrenze den Zugriff und lege vorab fest, woran sich das Ergebnis messen lässt. So entsteht Schritt für Schritt ein belastbarer Harness für agentengestützte Entwicklung und gleichzeitig ein Arbeitsmodell, in dem das Wissen von Salesforce Admins und Developern weiterhin eine zentrale Rolle spielt.