Gepubliceerd: 12 juni 2026 | Leestijd: 7 minuten | Categorie: Salesforce
TL;DR
Het bouwen van een Agentforce Service Agent voor lead capture vereist het veilig beheren van state over meerdere beurten. Hoewel standaard Flows geweldig zijn voor eenvoudige taken, maakt een Apex @InvocableMethod het mogelijk om state persistent bij te houden over conversatiebeurten en veilige USER_MODE DML-operaties uit te voeren. Hier leest u precies hoe u er een bouwt.
Introductie: Het Agentforce Tijdperk
Salesforce Agentforce heeft de manier waarop we denken over geautomatiseerde klantinteracties volledig veranderd. We evolueren van rigide, boomstructuur chatbots naar autonome agenten die kunnen redeneren, verduidelijkende vragen stellen en acties kunnen uitvoeren.
Een van de meest voorkomende vroege use cases voor Agentforce is Lead Capture. Het doel is simpel: een AI-agent vraagt de gebruiker om hun informatie (bijv. Achternaam en Bedrijf), bewaart deze informatie gedurende meerdere conversatiebeurten en maakt een Salesforce Lead-record aan zodra alle vereiste gegevens zijn verzameld.
Hoewel u dit zou kunnen proberen met een schermflow of een automatisch gestarte flow, bieden Apex invocable actions aanzienlijk meer controle over state management en beveiligingscontext.
Hier is het exacte blauwdruk voor een productieklare Lead Capture Agent in 2026.
De Architectuur
Onze oplossing vereist drie kerncomponenten:
- De Agent Router (
start_agent): Verwelkomt de gebruiker en routeert deze naar de juiste subagent op basis van intentie. - De Lead Capture Subagent (
subagent): Instrueert de LLM over de exacte vereiste velden (Achternaam en Bedrijf) en triggert de actie. - De Apex Invocable Action (
@InvocableMethod): De daadwerkelijke "motor" die de input parseert, de state beheert en de database-insert uitvoert.
1. De Agent Script DSL
Agentforce gebruikt een specifieke Domain Specific Language (DSL) om het gedrag van de agent te definiëren. We definiëren variabelen om de input van de gebruiker over beurten heen op te slaan.
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"
De logica voor onze subagent dicteert dat we voor elke bericht dat de gebruiker stuurt terwijl deze zich in het lead capture-onderwerp bevindt, onze Apex-actie aanroepen. We geven het huidige userMessage door, samen met de last_name en company variabelen die we tot nu toe hebben verzameld.
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. De Apex Invocable Action
De ware kracht van dit patroon ligt in de Apex-klasse. In plaats van de LLM te laten raden wanneer de lead moet worden aangemaakt, gebruiken we een invocable actie om de bedrijfslogica veilig te beheren.
Waarom Apex boven Flow?
- Multi-turn state: Door
knownLastNameenknownCompanydoor te geven aan de Apex-actie enresolvedLastNameenresolvedCompanyterug te sturen, behouden we de conversatiestate perfect, zelfs als de gebruiker de informatie in de verkeerde volgorde verstrekt. - Beveiligingscontext: We kunnen Field Level Security (FLS) en CRUD-permissies dynamisch afdwingen met
AccessLevel.USER_MODE.
Hier is de structuur van de input- en outputvariabelen:
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
}
}
De leadId Binding Gotcha
Merk op dat public String leadId; is gedefinieerd als een String en niet als een Id. Dit is een cruciaal nuanceverschil in Agentforce. Bij het binden van de output van een invocable actie terug naar een Agent Script variabele (set @variables.last_lead_id = @outputs.leadId), geeft Agentforce de voorkeur aan primitieve stringtypen boven strikte Salesforce Id-typen. Het gebruik van Id kan leiden tot stille bindingsfouten tijdens de uitvoering.
3. Beveiliging Afdwingen met USER_MODE
Wanneer Agentforce een invocable actie uitvoert, draait deze onder de context van de Einstein Service Agent gebruiker (of uw geconfigureerde standaard agentgebruiker).
Als u probeert een lead in te voegen met standaard DML (insert newLead;), kan de systeemcontext noodzakelijke beveiligingscontroles omzeilen, of onvoorspelbaar falen, afhankelijk van de org-deelinstellingen.
De juiste aanpak in 2026 is om altijd user-mode DML af te dwingen:
Database.SaveResult sr = Database.insert(newLead, false, AccessLevel.USER_MODE);
De Ontbrekende Permission Set
Om de USER_MODE insert te laten werken, moet de Einstein Service Agent gebruiker de permissie hebben om Lead-records aan te maken.
U moet een Permission Set aanmaken (bijv. LeadCaptureAgent_Apex_Access) die het volgende verleent:
- Apex Class Access: Toegang tot uw
LeadCaptureTurnActionklasse. - Object Access: Lees- en Maak-permissies op het
Lead-object. - Field Permissions: Bewerkingsrechten voor
LastNameenCompany.
Wijs deze Permission Set toe aan de Einstein Service Agent gebruiker. Zonder dit zal de agent eindeloos blijven vragen om velden die hij al heeft verzameld, omdat de stille USER_MODE DML-fout voorkomt dat isSuccess ooit true retourneert.
4. De Agent Lokaal Testen
Voordat u publiceert, moet u de multi-turn logica valideren met de Salesforce CLI. Het commando sf agent preview stelt u in staat om de conversatie rechtstreeks vanuit uw terminal te simuleren.
# Start de sessie
sf agent preview start --json --authoring-bundle LeadCaptureAgent --use-live-actions --target-org my-org
# Stuur de eerste uiting (alleen Bedrijf)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My company is Acme Corp" --authoring-bundle LeadCaptureAgent --target-org my-org
# Stuur de tweede uiting (Achternaam)
sf agent preview send --json --session-id <SESSION_ID> --utterance "My last name is Smith" --authoring-bundle LeadCaptureAgent --target-org my-org
# Verifieer de Lead aanmaak
sf data query --query "SELECT Id, LastName, Company FROM Lead ORDER BY CreatedDate DESC LIMIT 1" --target-org my-org
De Bodemlijn
Agentforce stelt ons in staat om ongelooflijk dynamische conversatie-ervaringen te bouwen, maar het vereist een verschuiving in hoe we state en beveiliging beheren. Door lead capture via een speciale subagent te routeren en te vertrouwen op Apex invocable actions voor deterministische state management, zorgt u voor een veilige, veerkrachtige en gebruiksvriendelijke ervaring.
Vergeet niet om altijd String te gebruiken voor ID-outputs, USER_MODE DML af te dwingen en de juiste permission sets toe te wijzen aan uw agentgebruiker.
Over de Auteur: Deze gids is geschreven door het Resumity Technical Editorial team, dat de kruising verkent van moderne AI-platforms en enterprise CRM-architectuur.