Implementatie, headless en agentic in een partnerschap

Asset-intensieve organisaties draaien om een grote, langlevende installed base: machines, installaties, meters, leidingen of voertuigen die jaren of decennia in het veld staan en onderhouden moeten worden. Service-intensieve organisaties draaien om een hoog volume aan serviceprocessen rond die assets: storingen, inspecties, preventief onderhoud, installaties, garantieafhandeling en servicecontracten, vaak met een mobiele buitendienst.

In de praktijk zijn de meeste van onze klanten allebei tegelijk. Dat verandert de Salesforce-aanpak fundamenteel. Een klassieke Sales- of Service Cloud-inrichting modelleert vooral accounts, contacten en cases. Bij een asset- en service-intensieve organisatie is het asset zelf het hart van het datamodel: elk Salesforce Asset-record draagt de historie van installatie, configuratie, onderhoudsbeurten, storingen, entitlements en garantie. Het serviceproces, en steeds vaker ook het facturatieproces, bouw je daaromheen, niet andersom.

Concreet betekent dit: het Asset-object en Asset-hierarchieen als ruggengraat, Maintenance Plans voor terugkerend en preventief onderhoud, Work Orders en Work Order Line Items als de eenheid van uitvoering, Service Appointments voor planning, en facturatie op die installed base via Revenue Cloud. Het verschil met een standaardimplementatie zit in datamodellering en in de keten van service tot revenue, niet in een ander knopje aanzetten.

Wij dekken de volledige Salesforce-stack die service- en asset-intensieve organisaties nodig hebben, met Salesforce als kern en system-of-record.

• Service Cloud: de basis voor service- en asset-intensief werk, met cases, entitlements, kennisbeheer en omnichannel-support. Field Service is een uitbreiding op Service Cloud en deelt het Work Order-object, dus de service-afhandeling en de buitendienst leven op een fundament.
• Field Service: de mobiele en planningslaag bovenop Service Cloud. Work Orders beschrijven WAT er moet gebeuren en zijn gekoppeld aan account, contact en Asset; Service Appointments bepalen WANNEER en WAAR de monteur komt. De Dispatcher Console met Gantt-weergave plant op skills, beschikbaarheid en locatie, en de offline-first mobiele app laat technici zonder bereik doorwerken. Maintenance Plans, Maintenance Assets en Maintenance Work Rules (calendar-, criteria- of usage-based) genereren preventief en periodiek onderhoud vooruit op de installed base.
• Revenue Cloud / Revenue Lifecycle Management (RLM): het next-gen revenue-platform voor product catalog management, configure-price-quote, contract lifecycle management (amendments en renewals), order management en billing. Voor de installed base is vooral het asset-based en recurring of usage-based billing-model relevant: servicecontracten, onderhoudsabonnementen en verbruiksfacturatie van quote tot renewal zonder dataverlies. RLM, Revenue Cloud Advanced en Salesforce Revenue Cloud zijn hetzelfde platform onder geevolueerde naamgeving, native gebouwd op Salesforce Core (geen managed package).
• Salesforce CPQ: voor organisaties die nog op de bestaande CPQ managed package draaien. Sinds maart 2025 is Salesforce CPQ End of Sale en in maintenance mode: geen nieuwe klanten en geen nieuwe features, wel onderhoud en security, en bestaande klanten kunnen het blijven gebruiken en verlengen. Een officiele End-of-Life-datum bestaat niet; analisten verwachten uitfasering rond 2029-2030. Nieuwe implementaties zetten wij daarom op Revenue Cloud / RLM, en bestaande CPQ-omgevingen begeleiden wij richting dat platform.
• Headless Salesforce: de onderscheidende hoek, waarmee je dezelfde Salesforce-kern ontsluit naar custom portals, technician-apps en AI-agents.

Die capabilities versterken elkaar: Field Service genereert servicebezoeken op de installed base, en Revenue Cloud factureert diezelfde installed base en servicecontracten via asset- en usage-based billing.

Niet elke gebruiker hoort thuis in de standaard Salesforce-UI. Klanten willen een merkeigen portal, installateurs willen een snelle app op de bouwplaats, en partners willen alleen hun eigen orders zien. Daarvoor gebruiken we een headless-aanpak: Salesforce blijft de backend en de single source of truth, terwijl de frontend een losstaande, custom-branded applicatie is. Headless is geen manier om Salesforce te verlaten; het is een manier om Salesforce dieper in te zetten.

Die frontends praten met Salesforce via de open API-laag: REST- en GraphQL-API’s, de Connect REST API voor Experience Cloud-data, en Platform Events of streaming voor realtime updates. Salesforce positioneert dit nu expliciet onder de noemer Headless 360, dat elke grote platformfunctie beschikbaar maakt als API, als MCP-tool of als CLI-commando in plaats van uitsluitend via de browser-UI. De buitendienst-app kan een Lightning Web Component-app binnen Salesforce zijn, of een volledig eigen web- of mobiele app (bijvoorbeeld een React- of Next.js-frontend) op een veilige Salesforce-API-laag.

Het voordeel: volledige controle over merkbeleving, performance en gebruikerservaring, zonder de governance, security en data-integriteit van Salesforce op te geven. De backend houdt de business logic, de validaties en de single source of truth; de frontend levert precies de ervaring die de doelgroep nodig heeft. Dit is de brug tussen onze implementatie- en onze headless-praktijk.

Headless en custom development op Salesforce bouwen wij nu al sneller en betrouwbaarder met AI-coding-agents. Dit is toegepaste agentic engineering OP Salesforce: de agents werken op code en metadata in jouw eigen Salesforce DX-project, niet als een laag naast het platform.

Wij zetten Claude Code en OpenAI Codex in, en breder MCP-compatibele agents zoals Cursor en Windsurf, via het Model Context Protocol (MCP) en de Salesforce DX MCP Server. Daarmee bevraagt een agent objectschema’s, maakt en wijzigt Apex-klassen, triggers, Flows en validation rules, draait tests, maakt scratch orgs en deployt metadata, zonder de IDE of CLI te verlaten. Salesforce levert hierbij kwaliteitstooling zoals ApexGuru voor performance-insights op Apex en SLDS-richtlijntools. Het effect is een snellere en betrouwbaardere build op Salesforce DX en metadata, met menselijke review op elke stap.

De winst zit in tempo en consistentie bij het bouwen van precies de headless-portals, technician-apps en integraties die deze pagina beschrijft. Vendor-claims over tijdwinst presenteren wij als claim, niet als feit. Belangrijk: Salesforce levert de toegangslaag, niet de code-governancelaag. Eigen quality gates, code review, tests en deploy-gates blijven nodig en zijn onderdeel van de Outbirds-aanpak.

De kernzin is eenvoudig: jouw werkomgeving en data, altijd veilig en enterprise-grade. Hoe dat concreet wordt, verschilt tussen development en runtime.

Bij custom development werken de AI-coding-agents primair op broncode, metadata en configuratie, niet op productie-klantdata. Wij draaien sandbox- en scratch-first; een scratch org bevat per definitie geen data of metadata uit je productie-org. Klantdata blijft in de Salesforce-org en gaat niet naar het model. Tegelijk zijn we niet naief: de tools achter Headless 360 kunnen ook SOQL, DML en export tegen productie uitvoeren, en kunnen tegen een productie-org draaien met read-write toegang. Daarom perken wij toegang bewust in met een dedicated integration user volgens least privilege, org-allowlisting via de –orgs flag (en niet ALLOW_ALL_ORGS), en selectieve tools via de –tools flag. De org blijft system-of-record: agents erven identiteit, sharing rules, field-level security, permission sets, validation rules en governor limits, en vanaf API-versie 67.0 draaien database-operaties standaard in user mode.

Bij runtime-agents (Agentforce) zorgt de Einstein Trust Layer voor zero data retention en grounding, zodat klantdata niet bij het model achterblijft. Salesforce levert de toegangs- en hosting-laag; de code-governancelaag (review, tests, deploy-gates) verzorgen wij. Zo blijft Salesforce de kern en de single source of truth, terwijl headless en agentic dat fundament veilig verdiepen.

Wij zien deze drie niet als losse diensten maar als drie facetten van een partnerschap op hetzelfde Salesforce-fundament. Ze versterken elkaar in een roadmap.

1. Implementatie legt het fundament: het asset- en servicedatamodel, Service Cloud en Field Service, het revenue-model in Revenue Cloud / RLM, processen en integraties. Zonder een schone installed base, betrouwbare servicehistorie en een correct revenue-model heeft alles daarboven geen waarde.
2. Headless engineering opent dat fundament naar buiten: custom portals en technician-apps die de juiste mensen de juiste data geven via de API-laag, met Salesforce als onveranderde single source of truth. Dit is de onderscheidende hoek.
3. Agentic engineering heeft twee gezichten. Tijdens het bouwen versnellen AI-coding-agents (Claude Code, OpenAI Codex en MCP-compatibele agents zoals Cursor en Windsurf) de headless- en custom-development op Salesforce DX en metadata; dat is het bewijs dat Outbirds dit nu al doet. In runtime zetten we Agentforce-agents op dezelfde data en processen, bijvoorbeeld voor triage van storingsmeldingen of het voorbereiden van een Work Order.

De samenhang is geen toeval: agents zijn alleen betrouwbaar als ze op goed gemodelleerde, actuele data werken en via veilige interfaces handelen. Daarom is een partner voor alle drie de facetten een voordeel; er gaat geen context verloren tussen implementatie, frontend en AI.

De end-to-end keten loopt van een asset in het veld tot een afgehandelde serviceactie en de bijbehorende facturatie, met steeds minder handmatige tussenstappen. Een storingsmelding, via portal, telefoon, e-mail of een IoT-signaal, komt binnen als een gestructureerd record dat gekoppeld is aan het juiste Asset met zijn volledige historie.

Vanaf daar kan een Agentforce-agent de melding classificeren, eerdere storingen op hetzelfde asset herkennen, een waarschijnlijke oorzaak en de benodigde onderdelen voorstellen, en een Work Order voorbereiden. Field Service plant vervolgens de juiste monteur met de juiste skills en onderdelen in via een Service Appointment. De monteur werkt de Work Order af in de mobiele app, legt vast wat er is vervangen, en die data verrijkt de assethistorie weer. Aan de revenue-kant kan Revenue Cloud de uitgevoerde service, het onderhoudsabonnement of het verbruik op datzelfde asset factureren via recurring of usage-based billing.

Het resultaat is een lerende lus: betere first-time-fix, minder onnodige ritten, en servicemedewerkers die zich op de uitzonderingen richten in plaats van op routinewerk. Cruciaal blijft dat elke stap teruggrijpt op Salesforce als system-of-record, met de Einstein Trust Layer voor de runtime-agents, zodat de keten controleerbaar en auditeerbaar blijft.

De combinatie van een grote installed base, mobiele buitendienst, hoge servicevolumes en service- of verbruiksfacturatie komt in meerdere sectoren terug. Outbirds richt zich met deze aanpak op service-intensieve en asset-intensieve organisaties:

• Technische dienstverlening: installateurs, onderhoudsbedrijven en serviceorganisaties die werken op contracten en SLA’s met een gespreide buitendienst.
• Industrie en installatie: fabrikanten en machinebouwers met geinstalleerde apparatuur in het veld, serviceabonnementen en onderdelenlogistiek.
• Nutsbedrijven en utilities: netbeheer, energie en water met meters, aansluitingen en netwerkinfrastructuur, inclusief de warmtetransitie waar installatie- en monitoringprocessen sterk groeien.
• Publieke sector: organisaties die fysiek areaal, infrastructuur of voorzieningen beheren en daar service- en inspectieprocessen op draaien.

Wat deze sectoren delen is dat hun waarde in fysieke assets zit en hun continuiteit in service. Daar past een Salesforce-inrichting die het asset centraal stelt en de keten van service tot revenue sluit, niet een generieke CRM-uitrol.

Outbirds is een Nederlandse Salesforce-consultancy en officiele Salesforce-partner, opgericht in 2017, met specialisten die zowel platformimplementatie als moderne software-engineering beheersen. Die combinatie maakt ons geschikt voor de drie facetten die elders zelden onder een dak zitten: Salesforce-implementatie, headless engineering en agentic engineering voor service- en asset-intensieve organisaties.

We werken 100% agile en partnerschapsgedreven, in korte iteraties, dicht op jouw team, met de bedoeling je zelfstandig te maken in plaats van afhankelijk. Onze ervaring met Service Cloud, Field Service, Revenue Cloud / RLM en partnerproducten versterkt de service-, asset- en revenue-kant; onze engineeringpraktijk, inclusief het bouwen met AI-coding-agents, levert de headless portals, apps en agents daarbovenop. Salesforce blijft daarbij altijd de kern en het system-of-record.

Wil je weten hoe dit voor jouw installed base, serviceprocessen en servicecontracten uitpakt? We brengen graag in kaart welk facet, implementatie, headless of agentic, bij jouw situatie de meeste waarde toevoegt.

Wat is het verschil tussen asset-intensief en service-intensief?

Asset-intensief betekent dat de organisatie draait om een grote, langlevende installed base: machines, installaties, meters of voertuigen die jaren in het veld staan. Service-intensief betekent dat er een hoog volume aan serviceprocessen rond die assets loopt: storingen, inspecties, onderhoud, installaties en servicecontracten, vaak met een mobiele buitendienst. De meeste organisaties zijn beide tegelijk. In Salesforce vraagt dat om een inrichting waarin het Asset-object het hart van het datamodel vormt en het service- en facturatieproces daaromheen wordt gebouwd.

Welke Salesforce-capabilities zet Outbirds in voor asset- en service-intensieve organisaties?

Service Cloud als basis, met Field Service als uitbreiding daarop voor planning en mobiele buitendienst (gedeeld Work Order-object, met Maintenance Plans, Service Appointments en de Dispatcher Console). Voor de revenue-kant Revenue Cloud / Revenue Lifecycle Management (RLM) voor product catalog, quote-to-cash, contracten en asset-based of usage-based billing, en Salesforce CPQ voor organisaties die nog op de bestaande managed package draaien. En vooral headless Salesforce: custom portals, technician-apps en integraties op een API-first Salesforce-kern, plus AI-agents met Agentforce.

Wat maakt headless Salesforce de onderscheidende hoek?

In een headless-opzet blijft Salesforce de backend en de single source of truth, terwijl de frontend een losstaande, custom-branded applicatie is die via REST- en GraphQL-API’s, de Connect REST API en Platform Events communiceert. Salesforce noemt dit nu Headless 360, waarmee elke grote platformfunctie beschikbaar is als API, MCP-tool of CLI-commando. Zo houd je volledige controle over merkbeleving en gebruikerservaring zonder de governance, security en data-integriteit van Salesforce op te geven. Headless verlaat Salesforce niet; het zet Salesforce dieper in.

Hoe bouwt Outbirds headless development met AI-coding-agents, en blijft dat veilig?

Wij bouwen headless en custom Salesforce nu al sneller en betrouwbaarder met AI-coding-agents zoals Claude Code en OpenAI Codex, en breder MCP-compatibele agents zoals Cursor en Windsurf, via de Salesforce DX MCP Server. De agents werken op code en metadata in jouw eigen Salesforce DX-project; klantdata blijft in de Salesforce-org en gaat niet naar het model. We draaien sandbox- en scratch-first en perken toegang in met een least-privilege integration user, org-allowlisting (–orgs) en selectieve tools (–tools). De org blijft system-of-record en dwingt sharing rules, FLS en validation rules af. Salesforce levert de toegangslaag; de code-governance met eigen quality gates, review, tests en deploy-gates verzorgen wij.

Is Salesforce CPQ nog een goede keuze, of moet ik naar Revenue Cloud / RLM?

Salesforce CPQ (de bestaande managed package) is sinds maart 2025 End of Sale en in maintenance mode: geen nieuwe klanten en geen nieuwe features, wel onderhoud en security, en bestaande klanten kunnen blijven gebruiken en verlengen. Een officiele End-of-Life-datum bestaat niet; analisten verwachten uitfasering rond 2029-2030. Voor nieuwe implementaties is Revenue Cloud / Revenue Lifecycle Management (RLM) de strategische keuze: hetzelfde next-gen platform onder geevolueerde naamgeving, native gebouwd op Salesforce Core. Bestaande CPQ-omgevingen begeleiden wij richting dat platform.

Hoe passen implementatie, headless en agentic in een partnerschap?

Het zijn drie facetten van een partnerschap op hetzelfde Salesforce-fundament. Implementatie legt het asset- en servicedatamodel, Service Cloud, Field Service en het revenue-model in Revenue Cloud / RLM neer. Headless engineering opent die data via API’s naar custom portals en technician-apps; dat is de onderscheidende hoek. Agentic engineering kent twee gezichten: AI-coding-agents versnellen het bouwen op Salesforce DX en metadata, en Agentforce-agents handelen in runtime serviceacties af via de Einstein Trust Layer. Een partner voor alle drie de facetten voorkomt context-verlies tussen implementatie, frontend en AI.

Voor welke organisaties is deze Salesforce-aanpak geschikt?

Vooral voor service-intensieve en asset-intensieve organisaties: technische dienstverlening, industrie en installatie, nutsbedrijven en utilities (inclusief de warmtetransitie) en de publieke sector. Wat deze organisaties delen is dat hun waarde in fysieke assets zit en hun continuiteit in service. Daar past een Salesforce-inrichting die het asset centraal stelt en de keten van service tot revenue sluit, met Field Service voor de mobiele buitendienst en Revenue Cloud voor de facturatie, beter dan een generieke CRM-uitrol.