Setup with Agentforce: Admin-KI in Produktion erlauben?

Setup with Agentforce und Einstein for Flow gehören in eine Developer-Sandbox: als schneller Weg, Metadaten zu bauen, die danach wie jede andere Änderung über Repository und Pipeline laufen. In Produktion würde ich den Setup-Agenten für Fragen, Zugriffsanalyse und Benutzerverwaltung erlauben und für nichts, was Metadaten anlegt oder ändert. Der Agent fragt vor jeder Aktion nach Freigabe, aber diese Freigabe gibt derselbe Admin, der gefragt hat. Sie ersetzt weder ein zweites Augenpaar noch die Object Ownership Matrix noch das Deployment, das Produktion und Repository gleich hält.

Was kann der Setup-Agent ändern, und was dokumentiert Salesforce?

Setup with Agentforce ist ein Admin-Agent mit einem Button „Ask Setup Agent“ auf den Setup-Seiten. Salesforce hat am 26. Mai 2026 im Admin-Blog1 gemeldet, er sei „now Generally Available (GA)“, ohne ein Release zu nennen. Das Trailhead-Modul für Admins2 zählt auf, was er kann:

• Zugriffsprobleme von Benutzern analysieren und Benutzer verwalten
• Permission Sets, Permission Set Groups, organisationsweite Standards und Freigaberegeln pflegen
• eigene Objekte und Felder anlegen, Flows erstellen und ändern
• eigene Berichtstypen und Lightning-Seiten anlegen
• Formeln erstellen, ändern und erklären
• Fragen aus der Salesforce-Hilfe beantworten und über Org-Zustand, Nutzung und Lizenzen berichten

Für die Governance zählen drei Aussagen von Salesforce. In derselben Trailhead-Einheit steht: „The agent only takes action when you approve.“ Außerdem hilft der Agent nur bei Aufgaben, für die der Admin selbst die Rechte hat, und jede seiner Änderungen lässt sich im Setup Audit Trail nachvollziehen. Laut Objektreferenz3 enthält dieser Trail mindestens die letzten 180 Tage.

Bei den Kosten widersprechen sich die Quellen. Die Produktseite4 nennt 500 kostenlose Aktionen des Setup-Agenten pro Org und Monat, geteilt über alle Benutzer, und sagt, dass die Nutzung Data 360 Credits verbraucht. Der Admin-Blog nennt Setup-Aktionen nicht abrechnungspflichtig; nur die Aktion für Hilfe und Navigation verbrauche etwas Data 360 Credits und solle rund um Dreamforce 2026 auf ein anderes Framework umziehen. Nehmen wir drei Admins mit je 12 Anfragen pro Arbeitstag an: Das sind rund 750 Anfragen im Monat. Zählt jede Anfrage als eine Aktion, was keine Seite definiert, wäre das Kontingent in der dritten Woche aufgebraucht.

Ein unabhängiger Test lohnt einen Blick. Andy Engin Utkan hat den Agenten für Salesforce Break im Juli 20265 in einer Produktions-Org ausprobiert. Benutzer mit View All Data oder Modify All Data konnte der Agent nicht auflisten, sein Urteil: „This feature launched before it was fully baked.“ Das ist der Test eines einzelnen Autors, und die Flow-Erstellung hat er nicht geprüft. Den Überblick über alle Werkzeuge gibt das Masterclass-Kapitel zu Salesforce-Werkzeugen für KI-Entwicklung.

Einstein for Flow ist das engere Werkzeug. Laut Salesforce Ben6 ist es seit Spring ’25 GA, entwirft Flows mit bis zu etwa sechs Elementen, braucht die Berechtigung Manage Flows und verbraucht Einstein Requests in Produktion und Sandboxes. Der Entwurf wird nicht automatisch gespeichert.

Eine Agentenänderung in Produktion bricht den Release-Prozess

Ein geregeltes Salesforce-Programm beruht auf einer Regel: In Produktion steht, was im Repository steht, und jede Änderung kommt über die Pipeline dorthin. Warum, beschreibe ich in warum DevOps über Salesforce-Großprojekte entscheidet. Ein Feld, ein Flow oder eine Lightning-Seite, direkt in Produktion angelegt, bricht diese Regel, egal ob ein Mensch klickt oder ein Agent.

Der Agent verschärft das auf drei Wegen:

• Tempo. Ein Datenmodell mit sieben Feldern und einem Flow dauert Minuten. Pro Woche erreichen mehr direkte Änderungen die Produktion, und jede ist eine Abweichung zwischen Repository und Org.
• Die Freigabe sieht aus wie ein Review. Der Admin, der den Prompt geschrieben hat, bestätigt auch den Vorschlag. Niemand sonst prüft, ob das Objekt laut Object Ownership Matrix einem anderen Stream gehört, ob auf dem Objekt schon ein Flow läuft oder ob das Permission Set zu weit geht.
• Der Audit Trail zeigt was, nicht warum. Er zeigt die Änderung und einen Zeitstempel. User Story, Reviewer oder Test fehlen, und nach 180 Tagen brauchen Sie einen eigenen Export.

Dann kommt das nächste Deployment. Ein Partner deployt eine Lightning-Datensatzseite aus dem Repository, und das in Produktion ergänzte Feld verschwindet von der Seite. Die Validierung der Pipeline läuft gegen eine Sandbox ohne den neuen Flow und testet damit eine andere Org als die, in die sie deployt.

Sollte der Setup-Agent in Produktion erlaubt sein?

Ja, für einen festgelegten Teil seiner Arbeit. Ich trenne danach, ob eine Aktion Metadaten erzeugt, die ins Repository gehören.

Aktion	Produktion	Developer-Sandbox
Fragen, Hilfe, Org-Zustand, Lizenznutzung	erlaubt	erlaubt
Analysieren, warum ein Benutzer einen Datensatz nicht sieht	erlaubt	erlaubt
Benutzer sperren, Passwort zurücksetzen, vorhandenes Permission Set zuweisen	erlaubt wie bisher	erlaubt
Neues Permission Set, Freigaberegel, organisationsweiter Standard	nicht erlaubt	erlaubt, dann Pipeline
Objekte, Felder, Formeln, Berichtstypen	nicht erlaubt	erlaubt, dann Pipeline
Flows, Lightning-Seiten	nicht erlaubt	erlaubt, dann Pipeline

Benutzerverwaltung passiert in den meisten Orgs ohnehin in Produktion und läuft nie über ein Repository. Alles darunter sind Metadaten und folgt dem Release-Prozess.

Durchsetzen lässt sich das über Berechtigungen, nicht über ein Richtliniendokument. Salesforce sagt, der Agent kann nur, was der Admin darf. Die Frage lautet also, wer in Produktion Customize Application und vergleichbare Rechte hat. Haben sie nur der Release-User und ein Notfall-Admin, kann kein anderer Admin den Setup-Agenten in Produktion einen Flow bauen lassen, was auch immer der Button anbietet.

Rechenbeispiel: ein Feld für die Garantieverlängerung vor der Messe

Nehmen wir einen Maschinenbauer mit Service Cloud, Field Service für die Techniker im Außendienst und SAP als ERP an. Alle Zahlen sind Annahmen. Zwei Partner arbeiten an der Org: Partner A gehört laut Ownership Matrix das Objekt Asset, Partner B das Objekt Work Order. Drei interne Admins kümmern sich in Produktion um Benutzer und kleine Anfragen.

Die Serviceleitung möchte, dass die Hotline vor einer Messekampagne auf der Anlagenseite ein Datum „Garantie verlängert bis“ sieht. An einem Dienstag bittet eine Administratorin den Setup-Agenten in Produktion um das Feld, einen Platz auf der Asset-Datensatzseite und einen datensatzgesteuerten Flow, der das Datum aus dem Servicevertrag füllt. Der Agent schlägt die Lösung vor, die Administratorin bestätigt, nach zehn Minuten ist alles da.

Am Donnerstag deployt Partner A sein Sprint-Release, darin die Asset-Datensatzseite aus dem Repository. Das neue Feld verschwindet von der Seite. Der Flow läuft weiter, neben dem Flow von Partner A, der das Garantieende schon aus dem Installationsdatum berechnet. In der Woche darauf nennt die Hotline einem Händler zwei verschiedene Garantiedaten. Der Setup Audit Trail zeigt die Änderungen, aber kein Ticket und keinen Grund.

Dieselbe Anfrage in einer Developer-Sandbox mit Source Tracking hätte ebenfalls zehn Minuten gedauert. Die Administratorin holt die Änderungen in einen Branch, öffnet einen Pull Request, Partner A prüft ihn als Owner von Asset und führt die beiden Flows zu einem zusammen. Das Feld kommt mit dem nächsten Release in Produktion, rund eine Woche später.

Die Pipeline-Regel neben die Ownership Matrix schreiben

Release-Prozess und Rechtemodell für Admin-KI aufzusetzen ist Teil meiner Arbeit in DevOps und Release-Management. Die Reihenfolge folgt den Rechten: Was ein Admin in Produktion nicht darf, kann auch der Agent dort nicht.

1. 01

   Die Regel aufschreiben

   Metadatenänderungen kommen nur über die Pipeline in Produktion, egal ob ein Mensch, ein Partner oder ein Agent sie gebaut hat. Sie gehört neben die Ownership Matrix.

2. 02

   Rechte in Produktion prüfen

   Listen Sie auf, wer Customize Application und vergleichbare Berechtigungen hat. Genau diese Liste erbt der Setup-Agent.

3. 03

   Erst in Developer-Sandboxes

   Aktivieren Sie den Agenten zuerst in Developer-Sandboxes. Source Tracking (öffnet in einem neuen Tab) gibt es nur in Developer- und Developer-Pro-Sandboxes; dort lassen sich Agentenänderungen abrufen und landen in einem Pull Request.

4. 04

   Dieselben Prüfungen anwenden

   Flows und Felder aus dem Agenten bestehen dieselben Prüfungen wie Partnercode, wie in Quality Gates für KI-Code beschrieben.

5. 05

   Den Audit Trail lesen

   Prüfen Sie den Setup Audit Trail der Produktion wöchentlich auf Änderungen, die nicht vom Release-User stammen, und exportieren Sie ihn, bevor die 180 Tage ablaufen.

6. 06

   Den Verbrauch beobachten

   Verfolgen Sie die Nutzung gegen die 500 Aktionen und lassen Sie sich von Salesforce schriftlich bestätigen, wie Aktionen darüber abgerechnet werden.

Quellen6

1. 126. Mai 2026 im Admin-Blog (öffnet in einem neuen Tab)admin.salesforce.com
2. 2Trailhead-Modul für Admins (öffnet in einem neuen Tab)trailhead.salesforce.com
3. 3Objektreferenz (öffnet in einem neuen Tab)developer.salesforce.com
4. 4Produktseite (öffnet in einem neuen Tab)salesforce.com
5. 5Salesforce Break im Juli 2026 (öffnet in einem neuen Tab)salesforcebreak.com
6. 6Salesforce Ben (öffnet in einem neuen Tab)salesforceben.com