Salesforce Field Service is an extension of Service Cloud that provides a comprehensive view of workforce management.
Field Service involves providing services to customers beyond your office or site – which is referred to as in the “field”. Think about mobile employees, like service technicians, who carry out the service in-person; other people involved are service agents, dispatchers, and service managers. This guide will cover “what is Salesforce Field Service?”, who uses it, reporting, scheduling, optimization, and more.
What is Salesforce Field Service?
Salesforce Field Service, formerly known as Field Service Lightning (FSL), is the 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 – is all managed with Field Service Lightning.
Field Service Lightning is a Salesforce product that has evolved over time – and continues to. Often, functionality is added with each Salesforce release that passes. 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 to Service Cloud, sharing the “Work Order” object.
- Territory and scheduling: the related objects that facilitate the appointment booking (scheduling & optimization)
- Field Service user interface: the Field Service Dispatcher Console.
- Field Service Mobile App (for Android and iOS) – which 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 that support their customers.
The more “moving parts” involved with delivering the service, that involve specialized individuals coordinated in a sequence, then the more value FSL will deliver to organizations that use it.
Think about a high-end door installation company. The space for the door has to first be made into brick and structurally reinforced. 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: responds to customer “work orders” such as service call-outs. They will send the right person for the job, based on skill, availability, and proximity to the site.
- Field Technicians: the specialists carrying out the service, such as the installation crew.
- Service Agents: handles 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 (ie. how long the technician spent 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 make a call on who is best for the job. You’ll find Dispatchers using the “Dispatcher Console”.
- Field Technicians: use the Field Service Mobile app, as they are always “on the move” and also need offline capabilities to not disrupt their work.
- Service Agents: will initially work with a “Case”, to attempt to reach a resolution. When they validate a call-out visit is required, they then create a “Work Order” (which the dispatcher works on). You’ll find Service Agents using the “Lightning Service Console”.
- Service Managers: to monitor service efficiency and success, they will use 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 skillsets could be required according to the Work Order. Physical equipment could also be required.
- Maintenance: scheduled, repeated visits where the work follows a similar pattern each time.
- Sales: reps that visit prospects and customer sites (especially those who need to coordinate multiple single visits). Field Service can be sync easily with Opportunity records.
- Healthcare: care visits that happen regularly or irregularly.
Salesforce Field Service Terms
Before we progress any further, let’s cover the terms Salesforce Field Service you will 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: what work needs to be performed.
- Service Appointment: when and where, representing the visit the technician will make.
These two objects have many object 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, so you can “give your customers the level of support you’ve promised them”.
- Work Type: templates that can be applied to work orders and work order line items to standardize field service work that’s carried out for multiple customers.
- Service Territory: “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: allowable times for “when” teams can perform the work and when accounts can be serviced (taking their Entitlements and service contracts into account).
- Resource: any of the terms with “Resource” included indicate describe the “who” of the Work Order. This brings together service technicians level of expertise, hourly or job-based capacity, and more.
- Scheduling Policy: these bring together “where”, “when”, “who” factors in order to guide dispatchers when making a decision about which resource to send out. 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 you review 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 a robust data model and an optimized, guided usability that informs dispatchers to make 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 make a call on who is best for the job. The Dispatcher Console has been 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) offers flexibility in your internal operations, to move 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), versus background rules working to choose the best individual (Book Appointment action).
- “Get Candidates” shows intervals according to a resoure’s availability, versus offering a list of slots where teh resource is anomynous (Book Appointment action).
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” (source). “Auto-schedule” can also 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 would be is when it’s pushed to the mobile app for the field technician’s information.
6. 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, 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 completely 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 vs 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/secondary territory, where the field technician is sent for a period of a day or more. This would apply to long work orders, and/or ones that require highly-skilled individuals.
Field Service expert consultant, Aidan Flynn, explains territories in Field Service Lightning following “Big Dave” for the day, playing 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. Improve “first visit resolution” by supplying diagnostic information, and technicians can report back their progress with little friction. Plus, it’s built to be offline first so that capturing data isn’t dependent on a reliable connection.
Can be downloaded from the Apple or Google Play Store.
Visual Remote Assistant
Two-way video and audio between agent or field technicians and customers, creating 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, such as 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 clicking “New Report” on the Reports home page, you will be able to search for a service report that suits your needs. As you can see, there are many combinations of which object data is included. Plus, you can create custom report types, should you need to.
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 has the potential to 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 which needs to be installed into your Salesforce org.
- You will need to assign the Field Service licenses to users, as well as amend their profiles and permission sets.
- It’s highly likely you’ll have 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 which will 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 decide 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, and getting it right the first time will save headaches down the line and enable you to get value from FSL, faster.
There are consultants who specialize in FSL, who have attained the Field Service Consultant certification. While looking for credentials is a good benchmark, the real-life experience will always trump that.
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. Considering breaking up your requirements and considering what makes up the minimum viable product.
– Aidan Flynn, Brick Lane Consulting
Aidan provided this table that compares what is typically required in the first phase, and what could wait for a later phase:
| Minimum Viable Product (MVP) | Later Phases |
|---|---|
| Work Orders (plus how they're generated) & Work Types | Customized Scheduling Policies |
| Service Appointment (plus how they're generated) | Assets |
| Scheduling & Optimization. Out-of-the-box Scheduling Policies (plus rescheduling, cancellation) | Inventory |
| Dispatch | Self-service scheduling |
| Territories | SMS alerts |
| Service Resources & Skills | Finance & 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 & 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 & Sequencing | A “Travelling Salesman” approach to creating appointments which start near the base/home, and work 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 required. Or, it could be that it's unclear whether the Field Service mobile app will support 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 to go more smoothly from the outset.
- More UAT time required: Allocate more 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 as you’re looking in different directions through 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: Can be 2 day+ process to deploy FSL. This is due to FSL’s reliance on object data (not only metadata) as the main inputs that drive the processes (more on this, later).
- Take a long term view: It’s often an ongoing project, with ways to return and improve on what’s been done. Think in phases and take a long term view.
Salesforce Field Service Deployments
As we mentioned, deployments can be a process that lasts 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 often the support of additional technology is recommended.
Other risks to a smooth roll-out 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).
Summary
This Salesforce Field Service guide has covered all aspects of FSL – who uses it, the impacts it has, and the technical aspects. Projects involving Field Service are not the most simple to carry out – however, done right, FSL can be one of the most rewarding Salesforce products out there.
Comments: