Salesforce Field Service is an extension of Service Cloud that provides a comprehensive view of workforce management.
Field Service involves providing services to customers outside your office or site – referred to as “in the field.” Think of mobile employees, like service technicians, who perform the service in-person; other people involved include service agents, dispatchers, and service managers. This guide will cover what Salesforce Field Service is, who uses it, reporting, scheduling, optimization, and more.
What Is Salesforce Field Service?
Salesforce Field Service, formerly known as Field Service Lightning (FSL), is an extension of Service Cloud that provides a comprehensive view of workforce management.
Simply put, when a customer orders a new cable service, the cable installer will show up – where they are now, where they’re going, and how many meters of cable are in their van are all managed with Field Service Lightning.
Field Service Lightning is a Salesforce product that has evolved over time – and continues to do so. Often, functionality is added with each Salesforce release. Salesforce Field Service could be broken down into the following parts:
- Service Appointments: The central piece of the Field Service puzzle. Service Appointment records bring together standard Salesforce Service capabilities, plus territory and scheduling (described below).
- Salesforce Service Cloud: Field Service is closely aligned with Service Cloud, sharing the Work Order object.
- Territory and Scheduling: The related objects that facilitate appointment booking (scheduling and optimization)
- Field Service User Interface: The Field Service Dispatcher Console.
- Field Service Mobile App (for Android and iOS): Includes offline capabilities.
The data model diagram helps to describe the relationship between Service Cloud and Field Service:
Who Uses Salesforce Field Service?
Salesforce Field Service is valuable to organizations with mobile field technicians who support their customers.
The more ‘moving parts’ involved in delivering the service – that is, specialized individuals coordinated in a sequence – the more value FSL will deliver to organizations that use it.
Think about a high-end door installation company. The space for the door must first be prepared by making it into brick and structurally reinforcing it. The new door has to be delivered before it makes sense to send the door-fitting crew. The installation requires the customer’s signature as approval.
These service scenarios involve multiple people:
- Dispatchers: Respond to customer “Work Orders” such as service call-outs. They send the right person for the job based on skill, availability, and proximity to the site.
- Field Technicians: Specialists who carry out the service, such as the installation crew.
- Service Agents: Handle communication with customers when they request a service call-out. They validate the need for a call-out or whether there’s an alternative, easier resolution.
- Service Managers: Monitor service call-out volume, service efficiency (i.e. how long the technician spends at the site, travel time), and customer satisfaction.
Each of these people (personas) uses Salesforce Field Service in a different way:
- Dispatchers: Need to access multiple pieces of information simultaneously in order to decide who is best for the job. You’ll find dispatchers using the Dispatcher Console.
- Field Technicians: Use the Field Service Mobile app because they are always ‘on the move’ and also need offline capabilities to avoid disruptions to their work.
- Service Agents: Initially work with a “Case” to attempt a resolution. When they validate that a call-out visit is required, they create a “Work Order” (which the dispatcher then works on). You’ll find service agents using the Lightning Service Console.
- Service Managers: Monitor service efficiency and success using a combination of Salesforce reports, list views, and other Salesforce platform analytics.
Salesforce Field Service Use Cases
- Repairs: Visiting customer sites to carry out service, either as a single visit or multiple. Specific skill sets may be required according to the Work Order. Physical equipment might also be needed.
- Maintenance: Scheduled, repeated visits where the work follows a similar pattern each time.
- Sales: Reps who visit prospects and customer sites (especially those who need to coordinate multiple single visits). Field Service can be easily synced with Opportunity records.
- Healthcare: Care visits that happen regularly or irregularly.
Salesforce Field Service Terms
Before we progress any further, let’s cover the Salesforce Field Service terms you’ll see used frequently. I love the way the developer.salesforce.com documentation approaches FSL terms – splitting them into the question words: what, where, when, and who.
Work Orders vs. Service Appointments
These two objects sound similar, but each plays a different role:
- Work Orders: Define what work needs to be performed.
- ServiceAppointment: Define when and where, representing the visit the technician will make.
These two objects have many relationships that give FSL its robust data model and optimized, guided usability.
- Contract Line Items and Entitlements: Contracts are a standard object used across Salesforce. Line Items are the content of the contract. Entitlements are a Service Cloud object that enforces service-level agreements, allowing you to provide your customers with the level of support you’ve ‘promised’.
- Work Type: Templates that can be applied to Work Orders and Work Order Line Items to standardize field service work carried out for multiple customers.
- Service Territory: Refers to ‘where’ teams can perform the work. Geographic territories come to mind, as location is a fundamental factor in delivering efficient service. Territories can also be used for other types of divisions, such as distinguishing between sales vs. service boundaries.
- Operating Hours: Defines the allowable times for ‘when’ teams can perform work and when accounts can be serviced, taking their Entitlements and service contracts into account.
- Resource: Any term with “Resource” included describes the ‘who’ of the Work Order. This encompasses a service technician’s level of expertise, hourly or job-based capacity, and more.
- Scheduling Policy: Brings together the ‘where,’ ‘when,’ and ‘who’ factors to guide dispatchers in deciding which resource to send. Example factors that could be taken into consideration in your org include business priorities, travel time, and customer preferences. Four standard scheduling policies come out of the box.
I highly recommend reviewing the Salesforce Field Service data model to solidify your understanding of these terms and how they work together – like “cogs” that power the FSL “machine”.
Salesforce Field Service Scheduling and Optimization
As I mentioned, the FSL objects make up a robust data model and provide optimized, guided usability that informs dispatchers in making the best decision on who to send out at any given time.
Dispatcher Console
Scheduling in Salesforce Field Service is managed by the dispatcher using the Dispatcher Console UI. Dispatchers need to access multiple pieces of information simultaneously in order to determine who is best for the job. The Dispatcher Console is designed with a split panel (showing the Gantt chart on the right-hand panel), tabs, and selectors to toggle between policies.
Ways to Schedule Appointments
There are multiple ways appointments can make their way into the Dispatcher’s Gantt view – from manual to part-automated, to fully automated.
1. Book Appointment Action
Presents the service agent arrival ‘windows’ to choose from (as opposed to specific delivery times). This approach is a win-win because (a) the customer gets a reasonable indication, and (b) it offers flexibility in your internal operations to shift the exact time within the slot to optimize schedules, resource availability, etc.
2. Get Candidates Action
The Get Candidates action may appear similar to the “Book Appointment” action; however, there are two main differences.
- The service agent chooses a specific individual after evaluating their availability and slot rating (shown below), whereas the Book Appointment action uses background rules to choose the best individual.
- Get Candidates shows intervals according to a resource’s availability, whereas the Book Appointment action offers a list of slots where the resource is anonymous.
3. Auto-Create Appointments (Using the Work Type)
From Field Service Setup, you can enable “Auto-Create Service Appointment” when configuring Work Types. This will “generate a child service appointment when a Work Order or Work Order Line Item is created from the Work Type.” Additionally, Auto-schedule can be launched from the Service Appointment, which automatically finds the best available slot based on the scheduling policy.
4. Auto-Create Appointments (Using the Maintenance Plan)
Maintenance Plans can be used to create Work Orders on a schedule (e.g. planned maintenance visits every month). This completely automates the scheduling process – the first time a human has contact with the appointment is when it’s pushed to the mobile app for the field technician’s information.
5. Custom Appointment Booking
Beyond clicks, there’s always code! Appointment scheduling can be extended beyond the options the Field Service package offers. Custom interfaces could solve specific use cases; for example, they can expose scheduling functionality to in-store staff.
When it’s not practical to give Salesforce licenses to these users, Lightning Web Components or Sites can be used to call the GetSlots API and deliver a fully customized booking experience.
Service Territory Design
Service Territories define the ‘where’ teams can perform the work. Geographic territories come to mind, as the location is a fundamental factor in delivering efficient service. Territories can also be used for other types of divisions, such as distinguishing between sales and service boundaries.
A lack of attention to territory design can seriously impact the dispatcher’s satisfaction with the system. Serious thought is required in the initial design and ongoing maintenance – even minor changes can vastly improve or damage user productivity.
What Are Service Territory Types?
Service Territories are categorized into three types, evolving around a field technician:
- Primary Territory: A field technician’s “home patch.” This is where the majority of their work is carried out.
- Secondary Territory: A territory next to the primary territory, where the field technician sometimes has appointments.
- Relocation Territory: A territory far from the primary or secondary territory, where the field technician is sent for a period of a day or more. This applies to long work orders and/or those that require highly skilled individuals.
Field Service expert consultant Aidan Flynn explains territories in Field Service Lightning by following “Big Dave” for the day, who plays the “starring role.” Big Dave’s big day uses real-life examples of territory-based challenges Aidan and his team faced when implementing Service Territories.
Field Service Mobile
The Salesforce Field Service mobile app is a core part for mobile workforces on the move. Technicians get the information they need to optimize their jobs and travel between locations. It helps improve ‘first visit resolution’ by supplying diagnostic information, and technicians can report back their progress with minimal friction. Plus, it’s built to be offline-first, so capturing data isn’t dependent on a reliable connection.
The app can be downloaded from the Apple App Store or Google Play Store.
Visual Remote Assistant
Two-way video and audio between agents or field technicians and customers creates stronger relationships and personalized experiences for consultations with everyone from financial advisors to doctors to mechanics who can troubleshoot car problems remotely.
Salesforce Field Service Reporting
There are different options to monitor service efficiency and success depending on the persona, such as Salesforce reports, list views, and other Salesforce platform analytics, like Tableau CRM.
Work Order List View
Displays Work Orders associated with accounts, so that anyone in the organization (even non-service teams) can see service call-outs at a glance.
Field Service Report Types
Being Salesforce objects, you can use Salesforce standard reports. When you click “New Report” on the Reports home page, you can search for a service report that suits your needs. As you can see, there are many combinations of object data included. Plus, you can create custom report types if needed.
How Do I Enable Field Service Lightning in Salesforce?
The best place to reference when setting up Salesforce Field Service is the official Salesforce documentation. The setup process can change with every release, so treat the documentation as the source of truth. There are a few things to be aware of:
- Field Service Lightning is a managed package that needs to be installed into your Salesforce org.
- You will need to assign the Field Service licenses to users and amend their profiles and permission sets.
- It’s highly likely you’ll need to do some light configuration on standard objects such as Products, Assets, Service Contracts, and Entitlements
- Service Territories, Service Resources, and Operating Hours records will need to be created, as they become the framework for your service model.
Salesforce Field Service Projects
If you are looking to roll out Field Service in your organization, you may choose to do this ‘in-house’ (yourself or your colleagues), or you may outsource the technical implementation to a Salesforce partner consultancy. The depth of support documentation can be intimidating, but getting it right the first time will save headaches down the line and help you to get value from FSL faster.
There are consultants who specialize in FSL and have attained the Field Service Consultant certification. While credentials are a good benchmark, real-life experience will always carry more weight.
Keep the Field Service process in mind when scoping out your project:
“In most Field Service projects, there will be a wishlist that stretches far beyond the budget. This involves considering breaking up your requirements and what makes up the minimum viable product.” Aidan Flynn, Brick Lane
Aidan provided this table comparing what is typically required in the first phase and what could wait for a later phase:
| Minimum Viable Product (MVP) | Later Phases |
|---|---|
| Work Orders (+ How They're Generated) and Work Types | Customized Scheduling Policies |
| Service Appointment (+ How They're Generated) | Assets |
| Scheduling and Optimization; Out-of-the-Box Scheduling Policies (+ Rescheduling and Cancellation) | Inventory |
| Dispatch | Self-Service Scheduling |
| Territories | SMS Alerts |
| Service Resources and Skills | Finance and Billing |
| Signatures | – |
| Mobile Apps (Plus Processes) | – |
Simple vs. Complex Requirements
| Simple Requirements | Complex Requirements | |
|---|---|---|
| Work Types | Common Work Types are identified. These can be used to automatically define durations, skills, and materials required. | No consideration has been given to identifying repetitive tasks, or that trying to template repetitive tasks into Work Types is not an appropriate fit for the business. |
| Jobs | Jobs are single visit/resource, such as break/fix, maintenance, repairs, or sales visits. | Jobs are multi-stage, take more than a day, require more than one resource. They also have scheduling or manufacturing dependencies. |
| Team Processes | Follow similar processes with only a few variations. | There are very different processes for specific business functions to the extent that each business unit should be treated individually. |
| Scheduling and Optimization | The out-of-the-box scheduling policies are a good fit for all resources. | Custom scheduling policies with different rules for different parts of the business. |
| Scheduling and Sequencing | A “Travelling Salesman” approach to create appointments, starting near the base/home and working their way back towards it. | Resistance to move from approaches, such as feeling the need to manually control the sequence and shape of the schedule. |
| Handling Bookings | Booking is handled within Salesforce by the service team. | Booking is self-service and done via by external systems. |
| Territories | Territories are clearly defined with boundaries, which are rarely crossed by technicians. Geographically small, with up to 20 people. | Many primary, secondary, and temporary relocation territories. These change frequently or are “rostered” to share the travel between different resources week-to-week. |
| Gantt Views | The out-of-the-box Gantt is a good fit for all dispatchers. | Customizations, such as Custom Actions, are required to achieve what the dispatchers need. |
| Finance | Information available on the Service Appointment is enough for the finance team to use for processing. | Complex handling for finance is required, e.g. measuring billed vs. unbilled time or calculating billable time based on variables. |
| Mobile Apps | All requirements for mobile can be achieved within the Field Service mobile app. | Custom components, pages, and flows for mobile are required. Alternatively, it may be unclear whether the Field Service mobile app will support the requirements altogether. |
Salesforce Field Service vs. Service Cloud Projects
Having worked on dozens of Field Service and hundreds of Service Cloud projects, Aidan noticed commonalities but also plenty of differences. If you have experienced a Service Cloud implementation, being aware of these can help your FSL project run more smoothly from the outset.
- More UAT Time Required: Allocate additional time for user acceptance testing (UAT) and include support post-go live. FSL has more ‘nooks and crannies’ than other Salesforce products. The end-to-end Field Service process is more time-consuming to build, test, and onboard users.
- Exception Handling Diagnosis: Troubleshooting can take longer because you’re looking in different directions throughout the system in order to find the problem.
- Project Management: Consider getting an experienced Project Manager to manage the change – both on the consultancy’s side and internally.
- Deployment: Deploying FSL can be a two-day-plus process due to its reliance on object data (not just metadata) as the main inputs driving the processes (more on this later).
- Take a Long Term View: It’s often an ongoing project with opportunities to return and improve on what’s been done. Think in phases and adopt a long-term view.
Salesforce Field Service Deployments
As we mentioned, deployments can be a process lasting days due to FSL’s reliance on object data (not only metadata). Record data is fundamental to FSL processes, providing the framework that FSL relies on; however, complex relational data is difficult to move between environments, and the support of additional technology is often recommended.
Other risks to a smooth rollout can include a lack of buy-in from leadership and a large scheduling team that feels threatened by the automation capabilities that could make their roles redundant (although, in reality, FSL makes them more productive).
Limits and Considerations in Salesforce Field Service
While Field Service offers a wide range of functionalities to enhance workforce management, it is still important to be aware of certain limits and considerations that may impact its effectiveness on your business. Understanding these limitations will help organizations make more informed decisions during implementation and ensure that the system is optimized for their specific needs.
With technicians being deployed every day, it’s easy to have users end up owning a whole lot of Service Appointments and Work Orders, leading to performance issues and data skew. This is not a hard limit, but it is recommended that child records stay below 10,000. For example, keep a Work Order’s Service Appointments (or Line Items) under 10,000.
The structure and purpose of Service Territories – whether they represent geographical areas, lines of business, or both – play a very important role in Field Service operations. The way Service Territories are created, including the type and number of Service Resources they have, directly influences key aspects such as how technicians are displayed in the Dispatch Console, scheduling and dispatching workflows, optimization processes, and more. Be aware to:
- Only have up to 50 Service Resources per territory
- Keep each service territory to a maximum of 1,000 Service Appointments per day
Summary
This Salesforce Field Service guide has covered all aspects of FSL – who uses it, its impacts, and the technical details.
Projects involving Field Service are not the simplest to carry out; however, when done right, FSL can be one of the most rewarding Salesforce products available.
Comments: