Implementation, headless and agentic in one partnership

Asset-intensive organisations revolve around a large, long-lived installed base: machines, installations, meters, pipelines or vehicles that stay in the field for years or decades and need maintenance. Service-intensive organisations revolve around a high volume of service processes around those assets: failures, inspections, preventive maintenance, installations, warranty handling and service contracts, often with a mobile field workforce.

In practice most of our customers are both at once. That fundamentally changes the Salesforce approach. A classic Sales or Service Cloud setup mainly models accounts, contacts and cases. In an asset- and service-intensive organisation, the asset itself is the heart of the data model: every Salesforce Asset record carries the history of installation, configuration, maintenance visits, failures, entitlements and warranty. You build the service process, and increasingly the billing process, around it, not the other way round.

Concretely this means: the Asset object and asset hierarchies as the backbone, Maintenance Plans for recurring and preventive maintenance, Work Orders and Work Order Line Items as the unit of execution, Service Appointments for planning, and billing on that installed base through Revenue Cloud. The difference from a standard implementation lies in data modelling and in the chain from service to revenue, not in switching on a different button.

We cover the full Salesforce stack that service- and asset-intensive organisations need, with Salesforce as the core and system of record.

• Service Cloud: the foundation for service- and asset-intensive work, with cases, entitlements, knowledge management and omnichannel support. Field Service is an extension of Service Cloud and shares the Work Order object, so service handling and the field workforce live on one foundation.
• Field Service: the mobile and planning layer on top of Service Cloud. Work Orders describe WHAT needs to happen and are linked to account, contact and Asset; Service Appointments determine WHEN and WHERE the engineer arrives. The Dispatcher Console with Gantt view plans on skills, availability and location, and the offline-first mobile app lets technicians keep working without coverage. Maintenance Plans, Maintenance Assets and Maintenance Work Rules (calendar-, criteria- or usage-based) generate preventive and periodic maintenance ahead of time on the installed base.
• Revenue Cloud / Revenue Lifecycle Management (RLM): the next-gen revenue platform for product catalog management, configure-price-quote, contract lifecycle management (amendments and renewals), order management and billing. For the installed base, the asset-based and recurring or usage-based billing model matters most: service contracts, maintenance subscriptions and consumption billing from quote to renewal without data loss. RLM, Revenue Cloud Advanced and Salesforce Revenue Cloud are the same platform under evolved naming, built natively on Salesforce Core (no managed package).
• Salesforce CPQ: for organisations still running the existing CPQ managed package. Since March 2025, Salesforce CPQ is End of Sale and in maintenance mode: no new customers and no new features, but maintenance and security continue, and existing customers can keep using and renewing it. There is no official End-of-Life date; analysts expect phase-out around 2029-2030. We therefore put new implementations on Revenue Cloud / RLM and guide existing CPQ environments towards that platform.
• Headless Salesforce: the differentiating angle, exposing the same Salesforce core to custom portals, technician apps and AI agents.

Those capabilities reinforce each other: Field Service generates service visits on the installed base, and Revenue Cloud bills that same installed base and its service contracts through asset- and usage-based billing.

Not every user belongs in the standard Salesforce UI. Customers want a branded portal, installers want a fast app on site, and partners only want to see their own orders. For that we use a headless approach: Salesforce remains the backend and the single source of truth, while the frontend is a separate, custom-branded application. Headless is not a way to leave Salesforce; it is a way to use Salesforce more deeply.

Those frontends talk to Salesforce through the open API layer: REST and GraphQL APIs, the Connect REST API for Experience Cloud data, and Platform Events or streaming for real-time updates. Salesforce now explicitly positions this under the Headless 360 banner, making every major platform function available as an API, an MCP tool or a CLI command instead of only through the browser UI. The field app can be a Lightning Web Component app inside Salesforce, or a fully custom web or mobile app (for example a React or Next.js frontend) on a secure Salesforce API layer.

The benefit: full control over brand experience, performance and user experience, without giving up Salesforce governance, security and data integrity. The backend keeps the business logic, the validations and the single source of truth; the frontend delivers exactly the experience the audience needs. This is the bridge between our implementation and our headless practice.

We already build headless and custom development on Salesforce faster and more reliably with AI coding agents. This is applied agentic engineering ON Salesforce: the agents work on code and metadata in your own Salesforce DX project, not as a layer next to the platform.

We use Claude Code and OpenAI Codex, and more broadly MCP-compatible agents such as Cursor and Windsurf, through the Model Context Protocol (MCP) and the Salesforce DX MCP Server. With that, an agent queries object schemas, creates and modifies Apex classes, triggers, Flows and validation rules, runs tests, creates scratch orgs and deploys metadata, without leaving the IDE or CLI. Salesforce provides quality tooling here such as ApexGuru for performance insights on Apex and SLDS guideline tools. The effect is a faster and more reliable build on Salesforce DX and metadata, with human review at every step.

The gain lies in pace and consistency when building exactly the headless portals, technician apps and integrations this page describes. Vendor claims about time savings we present as claims, not facts. Important: Salesforce provides the access layer, not the code governance layer. Your own quality gates, code review, tests and deploy gates remain necessary and are part of the Outbirds approach.

The core line is simple: your work environment and data, always secure and enterprise-grade. How that becomes concrete differs between development and runtime.

In custom development, the AI coding agents work primarily on source code, metadata and configuration, not on production customer data. We run sandbox- and scratch-first; a scratch org by definition contains no data or metadata from your production org. Customer data stays in the Salesforce org and does not go to the model. At the same time we are not naive: the tools behind Headless 360 can also run SOQL, DML and exports against production, with read-write access. That is why we deliberately restrict access with a dedicated least-privilege integration user, org allowlisting through the –orgs flag (and not ALLOW_ALL_ORGS), and selective tools through the –tools flag. The org remains the system of record: agents inherit identity, sharing rules, field-level security, permission sets, validation rules and governor limits, and from API version 67.0 onwards database operations run in user mode by default.

For runtime agents (Agentforce), the Einstein Trust Layer provides zero data retention and grounding, so customer data does not linger with the model. Salesforce provides the access and hosting layer; the code governance layer (review, tests, deploy gates) is ours. That keeps Salesforce the core and the single source of truth, while headless and agentic deepen that foundation safely.

We do not see these three as separate services but as three facets of one partnership on the same Salesforce foundation. They reinforce each other in one roadmap.

1. Implementation lays the foundation: the asset and service data model, Service Cloud and Field Service, the revenue model in Revenue Cloud / RLM, processes and integrations. Without a clean installed base, reliable service history and a correct revenue model, nothing above it has value.
2. Headless engineering opens that foundation outwards: custom portals and technician apps that give the right people the right data through the API layer, with Salesforce as the unchanged single source of truth. This is the differentiating angle.
3. Agentic engineering has two faces. During the build, AI coding agents (Claude Code, OpenAI Codex and MCP-compatible agents such as Cursor and Windsurf) accelerate headless and custom development on Salesforce DX and metadata; that is the proof that Outbirds already does this. At runtime, we put Agentforce agents on the same data and processes, for example for triaging fault reports or preparing a Work Order.

The coherence is no accident: agents are only reliable when they work on well-modelled, current data and act through secure interfaces. That is why one partner for all three facets is an advantage; no context is lost between implementation, frontend and AI.

The end-to-end chain runs from an asset in the field to a completed service action and its billing, with fewer and fewer manual steps in between. A fault report, through a portal, phone, email or an IoT signal, arrives as a structured record linked to the right Asset with its full history.

From there, an Agentforce agent can classify the report, recognise previous failures on the same asset, suggest a likely cause and the required parts, and prepare a Work Order. Field Service then schedules the right engineer with the right skills and parts through a Service Appointment. The engineer completes the Work Order in the mobile app, records what was replaced, and that data enriches the asset history again. On the revenue side, Revenue Cloud can bill the delivered service, the maintenance subscription or the consumption on that same asset through recurring or usage-based billing.

The result is a learning loop: better first-time fix, fewer unnecessary trips, and service staff focusing on the exceptions instead of routine work. Crucially, every step refers back to Salesforce as the system of record, with the Einstein Trust Layer for the runtime agents, keeping the chain controllable and auditable.

The combination of a large installed base, mobile field workforce, high service volumes and service or consumption billing recurs across several sectors. Outbirds focuses this approach on service-intensive and asset-intensive organisations:

• Technical services: installers, maintenance companies and service organisations working on contracts and SLAs with a distributed field workforce.
• Manufacturing and installation: manufacturers and machine builders with installed equipment in the field, service subscriptions and parts logistics.
• Utilities: grid operation, energy and water with meters, connections and network infrastructure, including the heat transition where installation and monitoring processes are growing rapidly.
• Public sector: organisations that manage physical assets, infrastructure or facilities and run service and inspection processes on them.

What these sectors share is that their value sits in physical assets and their continuity in service. That calls for a Salesforce setup that puts the asset at the centre and closes the chain from service to revenue, not a generic CRM rollout.

Outbirds is a Dutch Salesforce consultancy and official Salesforce partner, founded in 2017, with specialists who master both platform implementation and modern software engineering. That combination makes us suited for the three facets that rarely live under one roof elsewhere: Salesforce implementation, headless engineering and agentic engineering for service- and asset-intensive organisations.

We work 100% agile and partnership-driven, in short iterations, close to your team, with the intention of making you independent rather than dependent. Our experience with Service Cloud, Field Service, Revenue Cloud / RLM and partner products strengthens the service, asset and revenue side; our engineering practice, including building with AI coding agents, delivers the headless portals, apps and agents on top. Salesforce always remains the core and the system of record.

Want to know how this plays out for your installed base, service processes and service contracts? We are happy to map which facet, implementation, headless or agentic, adds the most value in your situation.

What is the difference between asset-intensive and service-intensive?

Asset-intensive means the organisation revolves around a large, long-lived installed base: machines, installations, meters or vehicles that stay in the field for years. Service-intensive means a high volume of service processes runs around those assets: failures, inspections, maintenance, installations and service contracts, often with a mobile field workforce. Most organisations are both at once. In Salesforce that calls for a setup where the Asset object forms the heart of the data model and the service and billing process is built around it.

Which Salesforce capabilities does Outbirds deploy for asset- and service-intensive organisations?

Service Cloud as the foundation, with Field Service as its extension for planning and the mobile workforce (shared Work Order object, with Maintenance Plans, Service Appointments and the Dispatcher Console). On the revenue side, Revenue Cloud / Revenue Lifecycle Management (RLM) for product catalog, quote-to-cash, contracts and asset-based or usage-based billing, and Salesforce CPQ for organisations still on the existing managed package. And above all headless Salesforce: custom portals, technician apps and integrations on an API-first Salesforce core, plus AI agents with Agentforce.

What makes headless Salesforce the differentiating angle?

In a headless setup, Salesforce remains the backend and the single source of truth, while the frontend is a separate, custom-branded application communicating through REST and GraphQL APIs, the Connect REST API and Platform Events. Salesforce now calls this Headless 360, making every major platform function available as an API, MCP tool or CLI command. You keep full control over brand experience and UX without giving up Salesforce governance, security and data integrity. Headless does not leave Salesforce; it uses Salesforce more deeply.

How does Outbirds build headless development with AI coding agents, and does that stay safe?

We already build headless and custom Salesforce faster and more reliably with AI coding agents such as Claude Code and OpenAI Codex, and more broadly MCP-compatible agents such as Cursor and Windsurf, through the Salesforce DX MCP Server. The agents work on code and metadata in your own Salesforce DX project; customer data stays in the Salesforce org and does not go to the model. We run sandbox- and scratch-first and restrict access with a least-privilege integration user, org allowlisting (–orgs) and selective tools (–tools). The org remains the system of record and enforces sharing rules, FLS and validation rules. Salesforce provides the access layer; the code governance with our own quality gates, review, tests and deploy gates is ours.

Is Salesforce CPQ still a good choice, or should I move to Revenue Cloud / RLM?

Salesforce CPQ (the existing managed package) has been End of Sale since March 2025 and is in maintenance mode: no new customers and no new features, but maintenance and security continue, and existing customers can keep using and renewing. There is no official End-of-Life date; analysts expect phase-out around 2029-2030. For new implementations, Revenue Cloud / Revenue Lifecycle Management (RLM) is the strategic choice: the same next-gen platform under evolved naming, built natively on Salesforce Core. We guide existing CPQ environments towards that platform.

How do implementation, headless and agentic fit in one partnership?

They are three facets of one partnership on the same Salesforce foundation. Implementation lays down the asset and service data model, Service Cloud, Field Service and the revenue model in Revenue Cloud / RLM. Headless engineering opens that data through APIs to custom portals and technician apps; that is the differentiating angle. Agentic engineering has two faces: AI coding agents accelerate building on Salesforce DX and metadata, and Agentforce agents handle service actions at runtime through the Einstein Trust Layer. One partner for all three facets prevents context loss between implementation, frontend and AI.

Which organisations is this Salesforce approach suited for?

Above all service-intensive and asset-intensive organisations: technical services, manufacturing and installation, utilities (including the heat transition) and the public sector. What these organisations share is that their value sits in physical assets and their continuity in service. That calls for a Salesforce setup that puts the asset at the centre and closes the chain from service to revenue, with Field Service for the mobile workforce and Revenue Cloud for billing, better than a generic CRM rollout.