Veröffentlicht: 12. Juni 2026 | Lesezeit: 7 Minuten | Kategorie: Salesforce

TL;DR

Der Aufbau eines Agentforce Service Agent zur Erfassung von Leads erfordert die sichere Verwaltung des Zustands über mehrere Gesprächsrunden hinweg. Während Standard-Flows für einfache Aufgaben gut geeignet sind, ermöglicht die Verwendung einer Apex @InvocableMethod die persistente Zustandsverfolgung über Gesprächsrunden hinweg und sichere DML-Operationen im USER_MODE. Hier erfahren Sie genau, wie Sie einen erstellen.

Einleitung: Die Agentforce-Ära

Salesforce Agentforce hat die Art und Weise, wie wir über automatisierte Kundeninteraktionen denken, komplett verändert. Wir bewegen uns von starren, baumbasierten Chatbots zu autonomen Agenten, die schlussfolgern, klärende Fragen stellen und Aktionen ausführen können.

Einer der häufigsten frühen Anwendungsfälle für Agentforce ist die Lead-Erfassung. Das Ziel ist einfach: Ein KI-Agent fragt den Benutzer nach seinen Informationen (z. B. Nachname und Firma), behält diese Informationen über mehrere Gesprächsrunden hinweg und erstellt einen Salesforce Lead-Datensatz, sobald alle erforderlichen Daten gesammelt sind.

Obwohl Sie dies mit einem Bildschirm-Flow oder einem automatisierten Flow versuchen könnten, bieten Apex Invocable Actions deutlich mehr Kontrolle über die Zustandsverwaltung und den Sicherheitskontext.

Hier ist der genaue Bauplan für einen produktionsreifen Lead Capture Agent im Jahr 2026.

Die Architektur

Unsere Lösung erfordert drei Kernkomponenten:

  1. Der Agent Router (start_agent): Begrüßt den Benutzer und leitet ihn basierend auf der Absicht zum richtigen Unteragenten weiter.
  2. Der Lead Capture Unteragent (subagent): Weist das LLM genau an, welche Felder erforderlich sind (Nachname und Firma) und löst die Aktion aus.
  3. Die Apex Invocable Action (@InvocableMethod): Die eigentliche "Engine", die die Eingabe parst, den Zustand verwaltet und die Datenbankeinfügung durchführt.

1. Das Agent Script DSL

Agentforce verwendet eine spezifische Domain Specific Language (DSL), um das Verhalten des Agenten zu definieren. Wir definieren Variablen, um die Eingaben des Benutzers über mehrere Runden hinweg zu speichern.

variables:
    last_name: mutable string = ""
        description: "Lead last name"
    company: mutable string = ""
        description: "Lead company"
    lead_created: mutable boolean = False
        description: "Whether the lead has already been created"
    last_lead_id: mutable string = ""
        description: "The most recently created Lead ID"

Die Logik unseres Unteragenten schreibt vor, dass wir für jede Nachricht, die der Benutzer sendet, während er sich im Lead-Capture-Thema befindet, unsere Apex-Aktion aufrufen. Wir übergeben die aktuelle userMessage zusammen mit den bisher gesammelten Variablen last_name und company.

subagent lead_capture:
    label: "Lead Capture"
    description: "Collect last name and company, then create a Salesforce Lead through Apex."
    reasoning:
        instructions: ->
            if @variables.lead_created == True:
                | A lead has already been created in this conversation. Share the Lead ID and ask if the user wants anything else.
            if @variables.lead_created == False:
                | Use Process Lead Capture Turn for every lead-capture message.
        actions:
            process_lead_turn: @actions.process_lead_turn
                    with userMessage = ...
                    with knownLastName = @variables.last_name
                    with knownCompany = @variables.company
                    set @variables.last_name = @outputs.resolvedLastName
                    set @variables.company = @outputs.resolvedCompany
                    set @variables.lead_created = @outputs.isSuccess
                    set @variables.last_lead_id = @outputs.leadId

2. Die Apex Invocable Action

Die wahre Stärke dieses Musters liegt in der Apex-Klasse. Anstatt dass das LLM rät, wann der Lead erstellt werden soll, verwenden wir eine Invocable Action, um die Geschäftslogik sicher zu verwalten.

Warum Apex statt Flow?

  • Zustand über mehrere Runden: Durch die Übergabe von knownLastName und knownCompany an die Apex-Aktion und die Rückgabe von resolvedLastName und resolvedCompany behalten wir den Gesprächszustand perfekt bei, auch wenn der Benutzer die Informationen in falscher Reihenfolge angibt.
  • Sicherheitskontext: Wir können Field Level Security (FLS) und CRUD-Berechtigungen dynamisch mit AccessLevel.USER_MODE erzwingen.

Hier ist die Struktur der Eingabe- und Ausgabevariablen:

public class LeadCaptureTurnAction {
    
    public class Request {
        @InvocableVariable(required=true label='User Message')
        public String userMessage;
        
        @InvocableVariable(label='Known Last Name')
        public String knownLastName;
        
        @InvocableVariable(label='Known Company')
        public String knownCompany;
    }
    
    public class Result {
        @InvocableVariable(label='Is Success')
        public Boolean isSuccess;
        
        @InvocableVariable(label='Lead ID')
        public String leadId; // GOTCHA: Must be String, not Id
        
        @InvocableVariable(label='Resolved Last Name')
        public String resolvedLastName;
        
        @InvocableVariable(label='Resolved Company')
        public String resolvedCompany;
        
        @InvocableVariable(label='Message')
        public String message;
    }
    
    @InvocableMethod(label='Process Lead Capture Turn')
    public static List<Result> processTurn(List<Request> requests) {
        // 1. Parse the userMessage for missing fields using Regex
        // 2. Combine found fields with knownLastName and knownCompany
        // 3. If both are present, insert the Lead
        // 4. Return the Result
    }
}

Das leadId Binding Gotcha

Beachten Sie, dass public String leadId; als String und nicht als Id definiert ist. Dies ist eine kritische Nuance in Agentforce. Beim Binden der Ausgabe einer Invocable Action zurück an eine Agent Script-Variable (set @variables.last_lead_id = @outputs.leadId) bevorzugt Agentforce stark primitive String-Typen gegenüber strikten Salesforce Id-Typen. Die Verwendung von Id kann während der Ausführung zu stillen Bindungsfehlern führen.

3. Erzwingen der Sicherheit mit USER_MODE

Wenn Agentforce eine Invocable Action ausführt, läuft diese im Kontext des Einstein Service Agent-Benutzers (oder Ihres konfigurierten Standard-Agentenbenutzers).

Wenn Sie versuchen, einen Lead mit Standard-DML (insert newLead;) einzufügen, kann der Systemkontext notwendige Sicherheitsprüfungen umgehen oder je nach Organisationsfreigabeeinstellungen unvorhersehbar fehlschlagen.

Der richtige Ansatz im Jahr 2026 ist immer die Erzwingung von DML im Benutzermodus:

Database.SaveResult sr = Database.insert(newLead, false, AccessLevel.USER_MODE);

Die fehlende Berechtigungsgruppe

Damit der USER_MODE-Einfügevorgang funktioniert, muss der Einstein Service Agent-Benutzer die Berechtigung zum Erstellen von Lead-Datensätzen haben.

Sie müssen eine Berechtigungsgruppe erstellen (z. B. LeadCaptureAgent_Apex_Access), die Folgendes gewährt:

  1. Apex Class Access: Zugriff auf Ihre LeadCaptureTurnAction-Klasse.
  2. Object Access: Lese- und Erstellungsberechtigungen für das Lead-Objekt.
  3. Field Permissions: Bearbeitungszugriff auf LastName und Company.

Weisen Sie diese Berechtigungsgruppe dem Einstein Service Agent-Benutzer zu. Ohne sie wird der Agent endlos Schleifen drehen und nach Feldern fragen, die er bereits gesammelt hat, da der stille USER_MODE-DML-Fehler verhindert, dass isSuccess jemals true zurückgibt.

4. Testen des Agenten lokal

Bevor Sie veröffentlichen, sollten Sie die Logik für mehrere Runden mit der Salesforce CLI validieren. Der Befehl sf agent preview ermöglicht es Ihnen, die Konversation direkt von Ihrem Terminal aus zu simulieren.

# Start the session
sf agent preview start --json --authoring-bundle LeadCaptureAgent --use-live-actions --target-org my-org

# Send the first utterance (Company only)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My company is Acme Corp" --authoring-bundle LeadCaptureAgent --target-org my-org

# Send the second utterance (Last Name)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My last name is Smith" --authoring-bundle LeadCaptureAgent --target-org my-org

# Verify the Lead creation
sf data query --query "SELECT Id, LastName, Company FROM Lead ORDER BY CreatedDate DESC LIMIT 1" --target-org my-org

Fazit

Agentforce ermöglicht es uns, unglaublich dynamische Konversationserlebnisse zu schaffen, erfordert aber eine Umstellung auf die Art und Weise, wie wir Zustand und Sicherheit handhaben. Indem Sie die Lead-Erfassung über einen dedizierten Unteragenten leiten und sich für eine deterministische Zustandsverwaltung auf Apex Invocable Actions verlassen, stellen Sie ein sicheres, widerstandsfähiges und benutzerfreundliches Erlebnis sicher.

Denken Sie immer daran, String für ID-Ausgaben zu verwenden, USER_MODE-DML zu erzwingen und die richtigen Berechtigungsgruppen für Ihren Agentenbenutzer zuzuweisen.

Über den Autor: Dieser Leitfaden wurde vom Resumity Technical Editorial Team verfasst und untersucht die Schnittstelle zwischen modernen KI-Plattformen und der Enterprise CRM-Architektur.