Headless 360, MCP en AI-coding-agents

Headless Salesforce is een architectuurpatroon waarbij je de backend (de Salesforce-data, business logic, validatieregels, automatisering en rechten) ontkoppelt van de frontend (de presentatielaag die de gebruiker ziet). De “head” is de interface; “headless” betekent dat je die head weglaat of vervangt door iets eigens.

In een traditionele Salesforce-opzet zijn data en UI sterk verweven: gebruikers loggen in op Lightning Experience of een Experience Cloud-site en de schermen worden door Salesforce zelf gerenderd. In een headless opzet exposeert Salesforce zijn capabilities via API’s, en consumeert een externe laag (een React- of Vue-app, een mobiele technician-app, een IoT-systeem of een AI-agent) die data. De gebruiker merkt vaak niet eens dat Salesforce de motor onder de kap is.

Belangrijk: headless is niet hetzelfde als “alleen API’s gebruiken”. Het is een bewuste keuze om de presentatielaag buiten het platform te leggen, terwijl je governance, security en datamodel binnen Salesforce houdt. Daardoor blijft Salesforce de single source of truth, ook als de interface volledig eigen is. Headless is geen manier om Salesforce te verlaten, maar een manier om het dieper en breder in te zetten.

Ja. Salesforce is technisch goed geschikt als backend of headless CRM, en dat was het in de praktijk al jaren voor de officiele term bestond. De bouwstenen waren er al langer: de REST en SOAP API’s, de Bulk en Streaming API’s, de Connect API, de Composite API voor het bundelen van calls, en User Interface API’s die metadata en layout-informatie teruggeven.

Service-intensieve en asset-intensieve organisaties gebruiken Salesforce-als-backend bijvoorbeeld voor een klantportaal met een eigen designsysteem, een buitendienst-app die offline werkt op de installed base, een verbruiks- of telemetrie-frontend voor assets, of een integratie waarin een ander systeem het scherm levert maar Salesforce de waarheid bewaart over klant, asset, work order en case.

De afweging zit niet in het kunnen, maar in het verstandig doen: authenticatie (OAuth 2.0, JWT bearer flow voor server-to-server), het respecteren van governor- en API-limieten, het bewaken van sharing rules en field-level security buiten de standaard-UI, en het beheersbaar houden van de extra codebase die je zelf onderhoudt. Dat is precies waar architectuurkeuzes en ervaring het verschil maken.

Salesforce Headless 360 is het programma dat Salesforce op TrailblazerDX (15 april 2026) presenteerde om het hele platform API-first te maken. Het principe: elke capability die voorheen een ingelogde gebruiker, een Setup-menu of een Lightning-pagina vereiste, wordt bereikbaar via drie oppervlakken. Volgens Salesforce gaat het om ruim 4.000 bestaande REST API’s, meer dan 60 nieuwe Model Context Protocol (MCP)-tools en meer dan 220 CLI-commando’s. Daarbovenop leveren ruim 30 voorgeconfigureerde coding skills context aan MCP-compatibele AI-coding-agents zoals Claude Code en Cursor, en breder agents zoals Codex en Windsurf.

Het Model Context Protocol (MCP) is een open standaard waarmee AI-agents tools kunnen ontdekken en aanroepen. In Salesforce-context betekent dit dat een agent dynamisch kan vinden welke acties beschikbaar zijn en die kan uitvoeren, met de juiste context: velddefinities, validatieregels en objectrelaties. Salesforce vat dit samen als “the new consumer is the agent”.

Het is goed om twee soorten MCP-servers uit elkaar te houden. De Salesforce DX MCP Server (Beta, standaard aanwezig in Code Builder) draait op de developer-machine, gebruikt lokale auth-bestanden en is bedoeld voor development tegen sandboxes en scratch orgs. De door Salesforce gehoste MCP-servers (GA voor Enterprise Edition en hoger) worden door Salesforce zelf gehost, geauthenticeerd en van permissiehandhaving voorzien, en bedienen vooral business- en runtime-scenario’s. Het zijn niet dezelfde dienst, en dat onderscheid is belangrijk voor zowel data-veiligheid als governance.

Headless is voor Outbirds geen toekomstbelofte maar dagelijkse praktijk. We helpen organisaties nu al headless en custom Salesforce te bouwen met AI-coding-agents: Claude Code en Cursor, en breder MCP-compatibele agents zoals Codex en Windsurf. Dit is toegepaste agentic engineering OP Salesforce: de agents werken in de IDE of CLI die de developer al gebruikt en spreken de org aan via MCP, zonder aparte toolchain.

Concreet bouwen die agents op je Salesforce DX-project en metadata. Via de DX MCP Server bevragen ze objectschema’s, schrijven en wijzigen ze Apex-klassen, triggers, flows en validation rules, draaien ze tests, maken ze scratch orgs en deployen ze metadata, zonder de IDE te verlaten. Kwaliteitstools zoals ApexGuru (die anti-patterns als SOQL of DML in loops markeert) en de coding skills met ingebouwde validator-hooks brengen reviews en best practices direct in de workflow. Het resultaat: sneller en betrouwbaarder bouwen op DX en metadata.

Dit is precies de basis onder een goede headless-architectuur. De API’s, de custom frontends, de integratielagen en de agent-tools die je headless inzet, worden zelf ook gebouwd, getest en gedeployd, en juist daar versnellen AI-coding-agents het werk. Implementatie, headless en agentic zijn voor ons dan ook geen drie losse producten, maar drie facetten van een partnerschap waarin Salesforce de kern blijft. Belangrijk om eerlijk te zijn: Salesforce levert de toegangslaag, maar geen ingebouwde code-governancelaag die agent-output automatisch toetst op technische schuld of conventies. Eigen quality gates, review, tests en deploy-gates blijven nodig en horen bij de Outbirds-aanpak.

Ja, mits je het bewust inricht. Kernzin: jouw werkomgeving en data, altijd veilig en enterprise-grade. Bij custom development werken de AI-coding-agents primair op broncode, metadata en configuratie in je eigen omgeving. We draaien sandbox-first en scratch-first; een scratch org bevat per definitie geen data of metadata uit je productie-org, dus je ontwikkelt en test zonder dat klantdata naar het model gaat. Klantdata blijft in de Salesforce-org.

Wees daarbij niet naief: de Headless 360-tools kunnen ook tegen productie draaien met read-write toegang en omvatten SOQL-queries, het aanmaken of bijwerken van records en data-export. De techniek staat dataverkeer dus toe. Daarom is bewuste inperking leidend. We werken met een dedicated integration user volgens least privilege, encrypted auth-bestanden, expliciete org-allowlisting (de –orgs flag, met ALLOW_ALL_ORGS afgeraden) en selectieve tools (de –tools flag), zodat een agent alleen kan wat hij echt moet kunnen.

De org blijft system-of-record. Headless 360 dwingt vier lagen af, ongeacht het toegangspunt: identiteit (de agent handelt als een specifieke user), toegang (sharing rules, field-level security en permission sets bepalen wat mag), invocation scope (alleen expliciet geexposeerde tools), en governance (validation rules, triggers, approval chains en governor limits vuren altijd). Vanaf API-versie 67.0 draaien database-operaties bovendien standaard in user mode, niet in system mode. Voor runtime-agents zoals Agentforce komt daar de Einstein Trust Layer bij, met zero data retention en grounding.

Headless levert het meeste op waar een eigen kanaal, een specifieke UX of asset-data het rechtvaardigen. Voor service-intensieve en asset-intensieve organisaties zien we vier terugkerende patronen.

Technician-apps en buitendienst: een eigen, offline-capabele app voor monteurs die work orders en service appointments toont en service-historie per asset bijwerkt, terwijl Salesforce (Service Cloud en Field Service, met het gedeelde Work Order-object) de waarheid bewaart. Field Service biedt hiervoor zelf al een offline-first mobiele app; headless is de keuze wanneer je een merk-eigen of sterk gespecialiseerde flow nodig hebt.

Klantportalen: een portaal met eigen designsysteem waar klanten contracten, onderhoudsabonnementen, openstaande cases en facturen op hun installed base zien. Voor veel portalen is Experience Cloud sneller en goedkoper; ga headless wanneer pixel-perfecte branding of een bestaand frontend-team de doorslag geeft.

IoT- en asset-data: telemetrie en verbruik van assets via Streaming en Bulk API’s of Data 360 het platform in, zodat preventief onderhoud (Maintenance Plans en Maintenance Assets) en usage-based facturatie in Revenue Cloud / RLM op echte gebruiksdata kunnen draaien.

Servicekanalen en agents: chat, messaging, stem of een AI-agent als ingang op dezelfde Salesforce-kern, waarbij de agent via MCP-tools precies de acties krijgt die je toestaat. Zo verbind je nieuwe kanalen zonder je datamodel of governance te versnipperen.

Deze drie termen beschrijven hoe sterk je systeem ontkoppeld is, en ze sluiten elkaar niet volledig uit.

Monolithisch betekent dat data, logica en interface een geheel vormen. Een standaard Salesforce-org met Lightning-pagina’s is in de kern monolithisch: snel op te zetten, weinig te onderhouden, maar je bent gebonden aan hoe Salesforce de UI rendert.

Composable verwijst naar een architectuur die is opgebouwd uit losse, herbruikbare business-capabilities (vaak via API’s) die je combineert als bouwstenen. Het gaat over modulariteit aan de backend- en integratiekant: je kiest per functie de beste dienst en koppelt die samen. Headless gaat specifiek over het ontkoppelen van de presentatielaag van de backend. Een systeem kan headless zijn zonder volledig composable te zijn, en composable zonder per se headless.

In de praktijk is het een glijdende schaal. Veel organisaties zijn het meest gebaat bij een hybride: het grootste deel binnen Salesforce (snel, governed, weinig onderhoud), en alleen die schermen of integraties headless waar een eigen UX, performance of een specifiek kanaal het echt vraagt.

Dit is de meest concrete headless-keuze waar Salesforce-klanten voor staan: laat je Salesforce de portal-schermen renderen (Experience Cloud) of bouw je een eigen frontend (bijvoorbeeld in React) op de API’s?

Experience Cloud is de juiste keuze wanneer: je snel live wilt, de UX dicht bij standaard Salesforce-patronen mag blijven, je weinig frontend-onderhoud wilt, en authenticatie, sharing en security uit de doos moeten komen. Je krijgt LWR-templates, ingebouwde Salesforce-identiteit en directe toegang tot het datamodel zonder eigen middleware.

Een custom React-frontend is de juiste keuze wanneer: je een merk-specifieke, pixel-perfecte UX of een complexe interactie nodig hebt die de standaard niet biedt, je een bestaand designsysteem of frontend-team hebt, of je dezelfde backend over meerdere kanalen (web, mobiel, kiosk, technician-app) wilt hergebruiken. De prijs: je onderhoudt zelf een codebase, je regelt zelf de hosting, en je moet expliciet zorgen dat sharing rules en field-level security in jouw laag worden gerespecteerd. Juist hier helpen AI-coding-agents om die eigen codebase sneller en met meer consistentie te bouwen en te onderhouden.

Nieuw sinds Headless 360 is de Multi-Framework-aanpak: React kan ook on-platform draaien. Het inbedden van React als micro-frontend binnen Lightning Experience was op het moment van schrijven in developer preview. Dat verkleint de historische tweedeling “kies React of de Salesforce-governance”: je kunt steeds vaker beide.

Headless geeft vrijheid, maar verplaatst complexiteit. De belangrijkste afwegingen:

Governor- en API-limieten blijven gelden. Een headless consument telt mee in dezelfde limieten als elke integratie. Bij een Enterprise-org is dat in de orde van grootte van 100.000 API-calls per 24 uur, met per transactie limieten als 100 SOQL-queries, 150 DML-statements en 6 MB heap. AI-agents kunnen die limieten sneller opdrogen: een agentgesprek bestaat vaak uit meerdere acties en kan in korte tijd veel queries afvuren. Concurrency en limietbewaking worden daarmee een ontwerpvraagstuk, geen bijzaak.

Security verschuift deels naar jouw verantwoordelijkheid waar je buiten de standaard-UI gaat. Headless 360 houdt identiteit, toegang, invocation scope en governance uniform overeind, maar in een eigen frontend moet je die uitkomsten ook correct presenteren en afdwingen. En omdat Salesforce wel de toegangslaag maar niet de code-governancelaag levert, blijven eigen review, tests en deploy-gates noodzakelijk.

Kosten zitten in onderhoud en kennis. Een eigen codebase, hosting, CI/CD, monitoring en een team dat zowel Salesforce als frontend begrijpt. Daar staat tegenover dat je betere UX, snellere kanaalonafhankelijke herontwikkeling en toekomstvaste agent-toegang krijgt, en dat AI-coding-agents de bouw- en onderhoudslast verlagen. De eerlijke vuistregel: ga headless waar het waarde toevoegt, en houd de rest gewoon op-platform.

Een eerlijk afwegingskader hoort erbij. Headless is vaak niet de beste keuze wanneer:

Je workflows overwegend sequentieel en transactioneel zijn en de standaard Lightning- of Experience Cloud-UX volstaat. Dan voegt een eigen frontend vooral onderhoud en risico toe zonder duidelijke winst.

Je API-budget krap is of je veel gelijktijdige gebruikers of agents verwacht; je loopt dan eerder tegen governor- en API-limieten aan dan je lief is.

Je geen frontend-capaciteit in huis of via een partner hebt om de zelfgebouwde laag duurzaam te onderhouden. Een headless project dat niemand onderhoudt, wordt technische schuld. Ook wanneer de behoefte vooral “snel live, standaard-UX, lage TCO” is, zijn Experience Cloud of standaard Lightning meestal sneller, goedkoper en veiliger.

Headless is een middel, geen doel. De juiste vraag is niet “hoe word ik headless?” maar “welke schermen, kanalen en agent-interacties vragen om ontkoppeling, en welke niet?”. Vaak is het antwoord een hybride architectuur: een governed Salesforce-kern, met gerichte headless-componenten waar UX, performance of een AI-agent dat rechtvaardigen. Zo voorkom je dat je de eenvoud en governance van het platform onnodig weggeeft.

Wat is headless Salesforce in een zin?

Headless Salesforce is het gebruik van Salesforce als API-first backend voor data, logica en workflows, terwijl de gebruikersinterface (de “head”) los daarvan draait, bijvoorbeeld als custom React-app, technician-app of AI-agent. Salesforce blijft daarbij de single source of truth.

Wat is Salesforce Headless 360?

Salesforce Headless 360 is het op TrailblazerDX (15 april 2026) gelanceerde programma dat elke Salesforce-capability bereikbaar maakt via ruim 4.000 REST API’s, meer dan 60 MCP-tools en meer dan 220 CLI-commando’s, ook zonder browser. Salesforce vat het samen met “the new consumer is the agent”: MCP-compatibele AI-agents kunnen het platform aansturen zoals voorheen alleen gebruikers en developers dat deden.

Bouwt Outbirds nu al headless en custom Salesforce met AI-coding-agents?

Ja. Outbirds helpt organisaties nu al headless en custom Salesforce te bouwen met AI-coding-agents zoals Claude Code en Cursor, en breder MCP-compatibele agents zoals Codex en Windsurf. Die agents werken op je Salesforce DX-project en metadata (Apex, flows, validation rules, tests, scratch orgs en deploys), sandbox-first en scratch-first, zodat je sneller en betrouwbaarder bouwt terwijl klantdata in de org blijft.

Is AI-ondersteund bouwen op Salesforce veilig en enterprise-grade?

Ja, mits bewust ingericht: jouw werkomgeving en data, altijd veilig en enterprise-grade. Bij custom development werken de agents primair op broncode, metadata en configuratie en draai je tegen sandbox of scratch orgs, waarin geen productie-klantdata zit. De Headless 360-tools kunnen technisch wel SOQL, DML en export tegen productie uitvoeren, dus we perken dat bewust in met een least-privilege integration user, org-allowlisting (–orgs) en selectieve tools (–tools). De org dwingt identiteit, sharing rules, field-level security en governor limits af; voor runtime-agents als Agentforce zorgt de Einstein Trust Layer voor zero data retention en grounding.

Welke headless use-cases passen bij service- en asset-intensieve organisaties?

Vooral vier: offline-capabele technician-apps op work orders en assets, klantportalen met eigen designsysteem op contracten en de installed base, IoT- en asset-data via Streaming, Bulk of Data 360 voor preventief onderhoud en usage-based facturatie, en servicekanalen of AI-agents als ingang op dezelfde Salesforce-kern.

Vervangt headless Salesforce mijn bestaande org?

Nee. Headless ontkoppelt de presentatielaag, maar je datamodel, automatisering, security en governance blijven in Salesforce, dat het system-of-record blijft. In de praktijk is een hybride het beste: een governed Salesforce-kern met gerichte headless-componenten waar een eigen UX, kanaal of AI-agent dat echt rechtvaardigt.

Gelden governor limits ook bij een headless Salesforce-architectuur?

Ja. Headless consumenten tellen mee in dezelfde governor- en API-limieten als elke integratie (bij Enterprise in de orde van 100.000 API-calls per 24 uur, en per transactie limieten als 100 SOQL-queries, 150 DML-statements en 6 MB heap). AI-agents kunnen die limieten sneller opdrogen, dus limietbewaking en concurrency horen vroeg in het ontwerp thuis.

Wanneer kies ik Experience Cloud in plaats van een custom front-end?

Kies Experience Cloud als je snel live wilt, een UX dicht bij standaard Salesforce volstaat en je weinig frontend-onderhoud wilt; identiteit, sharing en security komen dan uit de doos. Kies een custom (React) front-end als je een merk-specifieke UX, een bestaand designsysteem of kanaal-onafhankelijke herbruikbaarheid nodig hebt, en accepteer dat je dan zelf een codebase onderhoudt (waarbij AI-coding-agents het bouwen en onderhouden versnellen).