Headless Salesforce en MCP: CRM-acties uitvoeren vanuit één agentische hub

Het korte antwoord: headless Salesforce betekent dat de data, logica en workflows van het platform aanroepbaar zijn zonder de Lightning-UI, en een MCP-server is de standaardmanier om die aanroepen aan een AI-client aan te bieden. Samen leveren ze één actievlak op, zodat een agent, een Slack-thread of je eigen front end in dezelfde stap een CRM-actie en een ERP-actie kan uitvoeren. Salesforce maakte dit officieel op TrailblazerDX van 15 april 2026 met Headless 360, en de gehoste MCP-servers werden diezelfde maand algemeen beschikbaar voor Enterprise Edition en hoger.

Wat betekent headless Salesforce nu eigenlijk?

Het betekent dat de browser optioneel is. Elke mogelijkheid is bereikbaar als API, MCP-tool of CLI-commando, dus het system of record kan door iets anders dan een Lightning-pagina worden aangestuurd. Dat was precies de insteek op TrailblazerDX 2026, samen met meer dan 60 nieuwe MCP-tools en een experience layer die componenten rendert in Slack, Teams, mobiel en MCP-compatibele clients.

Twee verduidelijkingen, want beide worden door elkaar gehaald:

• Headless is niet UI-loos. Het betekent dat de interface een keuze is en geen afhankelijkheid. De meeste headless-implementaties hebben nog steeds een scherm, alleen is dat niet de org.
• Headless is geen vervanging van alles. Je objecten, flows, validatieregels en sharingmodel blijven precies waar ze zijn. Wat verandert is wie ze mag aanroepen.

Wat is een MCP-server in een Salesforce-context?

Een MCP-server publiceert een lijst tools die een AI-client kan aanroepen, met getypeerde invoer en een rechtenmodel erachter. In de praktijk kom je drie soorten tegen:

• Door Salesforce gehoste MCP-servers, algemeen beschikbaar sinds april 2026 voor Enterprise Edition en hoger, die orgdata, Flows, Apex invocable actions, AuraEnabled-methoden en named queries aanbieden.
• De Salesforce DX MCP-server, gericht op developerwerk zoals metadata deployen en Apex-tests draaien.
• Je eigen MCP-server, waar het interessante werk zit, want die is de enige die Salesforce en alles eromheen kan overspannen.

Het beveiligingsmodel is het deel om te onthouden. De gehoste server authenticeert per gebruiker met OAuth 2.0 en PKCE, en de agent handelt binnen de rechten van die gebruiker, waarbij CRUD, field-level security en sharing rules gewoon blijven gelden. Een agent is geen superuser.

Waarom zit de waarde in één actievlak en niet in een mooiere UI?

Hier zit het gat in vrijwel alles wat hierover wordt geschreven. Het meeste beschrijft Salesforce dat Salesforce ontsluit. Nuttig, maar daar zit de pijn niet.

Echt operationeel werk blijft niet binnen één systeem. "Keur deze kredietuitzondering goed, geef de order vrij en informeer de klant" is drie systemen en één intentie. Vandaag voert een mens die intentie uit door te wisselen tussen het CRM, het ERP en een telefonieconsole, en vertaalt daarbij handmatig. Elke vertaling is een kans om het fout te doen.

Eén actievlak vouwt dat tabbladwisselen samen tot één aanroepbare actie:

• De agent of het front end roept één tool aan.
• De tool orkestreert de CRM-schrijfactie, de ERP-aanroep en de notificatie.
• De rechtencontrole gebeurt één keer, op een plek die je kunt auditen.
• Een fout in een van de stappen is één fout, geen halfafgemaakt proces zonder eigenaar.

Een headless implementatie die alleen CRM ontsluit heeft de knoppen verplaatst. Eén die intenties ontsluit heeft de draaistoel weggehaald.

Hoe ziet één actiehub eruit over CRM en de omliggende systemen?

1. Salesforce blijft het system of record. Objecten, sharing en validatie blijven onaangeroerd.
2. Een MCP-laag publiceert intenties, geen tabellen. release_order, niet update_order_record.
3. Achter elke intentie zitten connectoren: ERP, finance, telefonie, planning, verbonden apparaten. Wij doen dit over meer dan 70 enterprisesystemen.
4. Eén identiteitsmodel. De rechten van de aanroeper bepalen wat de tool doet, in elk systeem dat hij raakt.
5. Clients zijn uitwisselbaar. Claude, Cursor, Agentforce, een Slack-app of je eigen front end roepen dezelfde tools aan.
6. Elke aanroep wordt vastgelegd als businessgebeurtenis, niet alleen als API-hit.

Tekunda bouwt deze vorm al sinds hij nog geen productnaam had, en voor zover wij weten zijn wij het eerste bureau dat headless CRM plus MCP-actiehubs in productie levert.

Wat gaat er bij de meeste teams mis?

• Objecten publiceren in plaats van acties. Een tool per object geeft een agent duizend manieren om rommel te maken. Een tool per bedrijfsintentie geeft hem één juiste manier.
• Idempotentie overslaan. Agents doen retries. Is release_order niet idempotent, dan verstuurt een retry de order twee keer.
• De agent de rechten laten bezitten. Draai als de gebruiker, niet als een integratieaccount dat alles mag.
• Geen goedkeuringsstap op onomkeerbare acties. Lezen mag vrij. Schrijven met een controle op alles wat financieel of klantgericht is.
• Het als integratieproject behandelen. Het is een interfaceontwerpproject dat toevallig integratie nodig heeft.

Waar begin je?

1. Kies één workflow die nu al twee systemen kruist en wekelijks iemand irriteert.
2. Schrijf de drie of vier intenties op die erin zitten, als werkwoorden.
3. Implementeer ze als MCP-tools, met getypeerde invoer, authenticatie per gebruiker en per stuk één auditregel.
4. Richt twee verschillende clients erop, bijvoorbeeld een agent en een Slack-actie, om te bewijzen dat het vlak echt gedeeld is.
5. Pas daarna breid je de catalogus uit.

FAQ

Betekent headless Salesforce dat je de Lightning-UI opgeeft?

Nee. Het maakt de UI optioneel. De meeste implementaties houden Lightning voor wie het prettig vindt en voegen andere ingangen toe voor wie dat niet zo is.

Is de door Salesforce gehoste MCP-server op zichzelf genoeg?

Genoeg om een AI-client in je org te laten werken. Niet genoeg voor acties die de org en andere systemen overspannen, en daar komt een eigen MCP-laag bij kijken.

Is een agent met MCP-toegang een beveiligingsrisico?

Hij draagt het risico van de identiteit waaronder hij draait. Met OAuth per gebruiker gelden CRUD, field-level security en sharing rules gewoon, dus het antwoord is de gebruiker afbakenen, niet de agent vertrouwen.

Hebben we Agentforce nodig om dit te doen?

Nee. MCP is een open standaard, dus Claude, Cursor en je eigen applicaties kunnen dezelfde tools aanroepen. Agentforce is één client van meerdere.

Tekunda bouwt headless Salesforce-implementaties en MCP-actiehubs over CRM, ERP, telefonie en verbonden apparaten. Wisselt je team tabbladen door een proces dat één actie zou moeten zijn, dan is dat de workflow om mee te beginnen.