Field Service for asset-intensive organisations

Salesforce Field Service (formerly Field Service Lightning, FSL) is not a standalone product but an extension of Service Cloud. Service Cloud provides the foundation: cases, entitlements, knowledge base and the customer and asset context. Field Service adds the field layer: a scheduling and optimisation engine with the Dispatcher Console, and an offline-capable mobile app for the engineer. Crucially, both share the same Work Order object. A Work Order describes WHAT needs to happen and is linked to account, contact and Asset, with Work Order Line Items as granular tasks. Service Appointments then determine WHEN and WHERE the work takes place.

Because Field Service runs entirely on the Salesforce platform, work orders, customers, contracts, assets and billing data live in the same data model as the rest of Sales Cloud, Service Cloud and Revenue Cloud. For asset-intensive and service-intensive organisations that is the essential difference from standalone FSM packages: no bridge is needed between the field organisation and the rest of the business, because it is one system with Salesforce as the system of record.

Field service management (FSM) is the end-to-end process of scheduling, dispatching, executing and completing work that happens outside your own walls: installations, inspections, repairs and maintenance at customers or on assets in the field. FSM software supports the whole chain, from incoming report or preventive maintenance moment, through planning and route optimisation, to execution by the engineer and invoicing.

When choosing FSM software, asset-intensive organisations weigh different criteria than purely reactive service companies. Key questions: do you manage an installed base with serial numbers and asset hierarchies, or do you mainly schedule loose jobs? Do you need preventive and usage-based maintenance, or only reactive calls? How many engineers and territories must the planning handle? And crucially: how well does it connect to your CRM, inventory, contracts and billing? A platform choice like Salesforce scores strongly when service, sales, asset data and revenue must come together in one system. A standalone FSM package can be cheaper for well-bounded, reactive scenarios, but then requires integration with the rest of the customer process.

The Field Service object model is built around a handful of standard objects that together describe the work and the capacity:

• Work Order: the central work object. It describes what needs to happen and for which account, asset or contract. Work Orders can contain Work Order Line Items for line-level detail. This object is shared with Service Cloud.
• Service Appointment: the schedulable unit that appears on the Gantt. The concrete visit with arrival, start and end time. A Work Order can have multiple Service Appointments.
• Service Resource: the engineer, crew or contractor performing the work. Service Resource Skills record capabilities, certifications and levels needed for matching.
• Service Territory: the geographic or functional work area that determines which resources qualify for which work and how the Gantt is organised.
• Work Type: the template that records standard duration, required skills and standard products for a type of work, so new Work Orders are created consistently.

Additional objects such as Resource Capacity (contractor capacity), Resource Absences (leave and absence) and Operating Hours/Time Slots make the planning realistic. This model is the foundation: every configuration choice, from scheduling policy to reporting, refers back to these objects.

For asset-intensive organisations, the Asset object is the heart of the solution. An Asset represents a specific installed Product at a customer or location, including serial number, installation date, warranty and status. Every customer installation is tracked in its own Asset record, linked to the Product object. Together those records form the installed base with service history and entitlements. Salesforce supports asset hierarchies through the Parent Asset and Root Asset fields, so you can model a complete installation, for example a production line with machines and, below them, components and parts, as a tree structure.

You link this installed base to Accounts, Locations (for example sites or technical rooms) and contracts. That way you know exactly where each asset is, who owns it, which warranty or service contract coverage applies, and its full maintenance and repair history. On the Asset you record every intervention through related Work Orders and Service Appointments, so you can analyse first-time fix, recurring failures and cost per asset. This asset-centric management is precisely the link to both maintenance (Maintenance Plans) and billing (asset-based billing in Revenue Cloud), and the reason Outbirds sets up asset-intensive customers on this model by default.

Preventive maintenance is handled natively in Field Service with Maintenance Plans. A Maintenance Plan links a set of assets to a maintenance schedule and automatically generates multiple Work Orders and Service Appointments ahead of time for future maintenance visits. The link between asset and plan runs through Maintenance Assets, which you can adjust per asset. Inspections and periodic maintenance are planned ahead instead of picked up only after a failure.

Maintenance Work Rules determine when and how often those Work Orders are created. Important: these rules are not limited to a fixed calendar. They can be calendar-based (for example every three months), criteria-based or usage-based, meaning based on actual consumption or operating hours (for example every 500 running hours). Usage-based maintenance is therefore a native Field Service capability, not an exclusive add-on of an extra package. Through Work Types on the plan, the generated Work Orders immediately receive the right standard duration, required skills and standard products. The result is a predictable, forward-planned maintenance calendar that lands directly in the Dispatcher Console and on the Gantt. For truly predictive maintenance based on advanced sensor and telemetry models you can go beyond the standard plans.

The installed base you build in Field Service is also the basis for recurring revenue. That is where Revenue Cloud (Revenue Lifecycle Management, RLM) comes in. Revenue Cloud is the successor to the old Salesforce CPQ managed package and covers the entire quote-to-cash and revenue lifecycle: Product Catalog Management, configure-price-quote, contract lifecycle management with amendments and renewals, order management, and billing and invoicing. For the installed base, the asset-based and usage-based billing model matters most: service contracts, maintenance subscriptions and consumption billing are invoiced traceably, from quote to order to renewal, without data loss.

That closes the loop. Field Service generates service visits and preventive maintenance on the assets, and Revenue Cloud bills those same assets and service contracts through recurring and usage-based models. Positioning the revenue stack correctly is part of this: Salesforce CPQ has been End of Sale since March 2025 and is in maintenance mode, so no new customers or features, but maintenance and security continue. Existing customers can keep using and renewing it for now. No official End-of-Life date has been announced (analysts expect roughly 2029-2030). Outbirds therefore sets up new projects on Revenue Cloud / RLM, which is built natively on Salesforce Core rather than as a managed package. RLM, Revenue Cloud Advanced and Revenue Cloud are the same next-gen platform under evolved naming, not three separate products.

Salesforce offers mature asset and maintenance capabilities out of the box: the Asset object with hierarchies, Maintenance Plans, Maintenance Assets, Maintenance Work Rules (calendar-, criteria- and usage-based) and standard maintenance history. For many maintenance, installation, manufacturing and utility organisations this native model fully covers the requirements, without an extra licence or package on top of Field Service. Usage-based maintenance is already included.

ServiceMax (part of PTC since the 2023 acquisition) is a paid extension that deepens asset-centric functionality on top of the native Salesforce objects. The difference is not in the basic principle of condition- or usage-based maintenance, because that is native, but in the depth: more extensive contract and warranty management, more advanced uptime and compliance features and specific workflows for heavily regulated, equipment-intensive sectors. It runs on the same platform and requires no integration, but it is a separate purchase. The trade-off: native asset management for those who need standard preventive, criteria- and usage-based maintenance, serial numbers and asset history, and ServiceMax when complex warranty and contract management or strict compliance requirements tip the balance. Outbirds advises independently on this and first checks what native can do before an extra package is considered.

The three options serve overlapping but different needs. Salesforce Field Service is the native extension of Service Cloud: maximum integration with CRM, sales, contracts and billing, a strong object model for assets and planning, and extensibility through Agentforce and the rest of the Salesforce ecosystem. It suits organisations that want to run service as part of one customer, asset and revenue picture.

ServiceMax is the asset-centric deepening for equipment-heavy and regulated sectors where uptime, warranty and compliance are central. It builds on Salesforce but is an extra package on top of the native capabilities.

FieldBuddy is an accessible FSM solution popular in the Benelux, focused on fast implementation and ease of use for service companies, and it can also be connected to Salesforce. For more compact, mainly reactive service processes FieldBuddy can be lighter. For organisations that want to consolidate service, asset management, contracts and billing in one platform, native Salesforce Field Service with Revenue Cloud is usually the strategic choice. Outbirds is a FieldBuddy partner and implements Salesforce Field Service, and can therefore compare independently based on your volume, asset complexity and integration needs.

Planning happens in the Dispatcher Console: a workspace with a Gantt view showing Service Appointments per engineer per day, next to a map with locations and routes. Dispatchers can drag appointments manually, or let the work be planned semi- or fully automatically.

The engine behind this is the scheduling engine with scheduling policies. A policy contains work rules (hard requirements, such as the right skill, availability and territory) and service objectives (soft preferences, such as minimising travel time or customer priority). The optimizer matches and replans appointments on skills, availability and location to minimise travel time, use capacity better and hit SLAs. Features such as drip feeding (an engineer only receives the next appointment after completing the current one) and automatic replanning on disruptions keep the schedule realistic. An offline-first mobile app lets technicians keep working without a connection. For asset-intensive organisations this means preventive maintenance visits, reactive failures and staffing constraints come together in one optimised schedule.

Agentforce adds agentic AI to Field Service, both for the planner and for the engineer in the field. For the field worker, Agentforce generates a pre-work briefing in the mobile app: an AI summary of the customer, the asset history, required parts and previous interventions, so the engineer arrives fully prepared. On the road, the AI can help with troubleshooting and with summarising and recording the work performed, lowering the administrative burden and raising first-time fix. On the planning side, AI agents support scheduling, dispatch and vendor coordination.

For these runtime agents, the Einstein Trust Layer provides zero data retention and grounding on your own org data: your work environment and data, always secure and enterprise-grade. Customer data stays in the Salesforce org and does not go to the model. Outbirds connects this Field Service AI to the broader agentic approach, so agents are not isolated but integrated into the full asset and service process.

Not all service and asset processes fit the standard Salesforce UI. Think of a customer portal for maintenance requests, a custom technician app or a connection with telemetry and IoT. For that, Outbirds uses headless Salesforce: the same Field Service and asset logic, exposed through APIs, while Salesforce remains the single source of truth and the access layer. Headless does not mean leaving Salesforce; it means using it more deeply.

Outbirds accelerates that headless and custom development with AI coding agents such as Claude Code and OpenAI Codex, and more broadly MCP-compatible agents such as Cursor and Windsurf. This is applied agentic engineering on Salesforce: building faster and more reliably on Salesforce DX, metadata and Apex. In this kind of custom development the agents work primarily on source code, metadata and configuration in your own environment, sandbox- and scratch-first, while customer data stays in the org. Salesforce provides the access layer but not the code governance layer, so our own quality gates, review, tests and deploy gates remain part of the Outbirds approach. Concretely we work with a least-privilege integration user, explicit org allowlisting and selective tools. That is how we keep the promise: your work environment and data, always secure and enterprise-grade.

What is the difference between Field Service Lightning and Salesforce Field Service?

There is no functional difference: Field Service Lightning (FSL) is simply the old product name. Salesforce renamed the product to Salesforce Field Service. You still encounter FSL in older documentation and in technical names of the managed package, but it is the same extension of Service Cloud, with a shared Work Order object.

Is condition-based or usage-based maintenance native in Field Service or do I need ServiceMax?

Usage-based maintenance is native. Maintenance Work Rules can be calendar-based, criteria-based or usage-based, so you can trigger maintenance based on actual operating hours or consumption without an extra package. ServiceMax (PTC) is a paid extension that does not add the basic principle but deepens it: more extensive warranty and contract management and more advanced compliance and uptime features for heavily regulated, equipment-intensive sectors. Check first whether native suffices before buying an extra package.

How do Service Cloud and Field Service relate to each other?

Service Cloud is the foundation for service- and asset-intensive work: cases, entitlements, knowledge and the customer and asset context. Field Service is the extension on top for the mobile workforce and scheduling. Both share the Work Order object. A Work Order describes WHAT needs to happen and is linked to an Asset, while Service Appointments determine WHEN and WHERE the engineer arrives. Field Service is not a standalone product next to Service Cloud.

How do I manage serial numbers and an installed base in Salesforce Field Service?

You record every installed Product as an Asset record with serial number, installation date, warranty and status, linked to the Product object. Through the Parent Asset and Root Asset fields you build asset hierarchies, so a complete installation with machines and components is modelled as one structure. You link Assets to Accounts, Locations and contracts, and all Work Orders and Service Appointments are related to them, so you can track the full history and cost per asset.

How do I bill service contracts and maintenance subscriptions on the installed base?

Through Revenue Cloud (Revenue Lifecycle Management, RLM), the successor to Salesforce CPQ. The asset-based and usage-based billing model supports service contracts, maintenance subscriptions and consumption billing, with amendments and renewals from quote to order to renewal without data loss. That way you bill the same assets and visits Field Service generates. CPQ has been End of Sale since March 2025 and is in maintenance mode (no official End-of-Life date), so new projects should target Revenue Cloud / RLM, native on Salesforce Core.

What does Agentforce do in Field Service concretely, and is it safe?

Agentforce delivers AI for planners and engineers: a pre-work summary in the mobile app with customer, asset and history data, support with troubleshooting and summarising completed work, plus help with scheduling and dispatch. For these runtime agents, the Einstein Trust Layer provides zero data retention and grounding on your own org data. Customer data stays in the Salesforce org and does not go to the model: your work environment and data, always secure and enterprise-grade.

Which sectors is Salesforce Field Service with Outbirds suited for?

Outbirds implements Field Service for service-intensive and asset-intensive organisations: technical services, manufacturing and installation, utilities and the public sector. In these sectors, installed-base management, preventive and usage-based maintenance, complex planning and installed-base billing come together, exactly the combination Service Cloud, Field Service and Revenue Cloud were built for on one platform.