Salesforce Field Service Lightning Functional Data Model 
Hey folks! During the last article on Salesforce Field Service Lightning (FSL), we discussed the features and benefits of using Salesforce FSL. Today, we will be discussing the data model of Field Service Lightning. This article will be slightly technical, so buckle up your seat belt hoses.
Salesforce Service Life Cycle
To understand the data model of Salesforce FSL and to get a complete gist of the system, let us first walk through a brief demonstration of the Salesforce Service Cycle.
Salesforce Service Cloud is implemented for catering to the service industry.
In the Service Cloud, a Case is routed and allocated under the available routing functionality utilized in the org after it reaches the last stage of the service cycle. Here, Field Service Lightning plays a significant role.
Field Service Lightning Setup
We first have to enable the Field Service Lightning in the Salesforce Setup. Once enabled, we install the managed package for Field Service Lightning which post-installation introduces a new data model in the system.
Field Service Lightning Data Model
From here FSL becomes the backbone of our process. FSL offers us two applications after its installation :
- Field Service for handling client-side data.
- Field Service Admin for handling the Salesforce side users.
Field Service Lightning Permissions and Configuration
Post-installation, we enable the Permissions in the Salesforce Field Service App.
Once enabled, these permissions are applied to our users in the form of permission sets as per the job requirement. For instance, we give our dispatchers access to the Dispatch Console while a Field Agent (Service Resource) gets access to the field service app.
Unleashing the Power of Salesforce: Exploring the Need for Custom Development
Dispatcher Service and Appointment Completion
Do you recall how FSL had a dispatcher console and resource management capabilities in our earlier article? The Dispatcher controls the Service Resources, Operating Hours, and Service Territories using the Dispatcher Console.
In FSL, Dispatcher creates a Work Order on the basis of the related Case. The Work Order leads to Service Appointment creation. The Service Appointment is the final record containing information about the Case. Service Appointment determines the Date, time, and Location of the Service Appointment. While this happens, a different story unfolds in another area of FSL.
Service Appointment is connected with Service Territories, Operating Hours, and Service Resources. Operating Hours for Service Territories are configured based on time zones. Service Resources complete the assigned Service Appointments within their operating hours and in their respective service territories. Service Appointments completion leads to the closing of a work order.
Once the field servicing work is completed, the system either closes the case or escalates it. This streamlined process ensures that all service requests are addressed in a timely and efficient manner. FSL also offers robust scheduling and dispatching capabilities, enabling businesses to optimize their resources and respond quickly to customer needs.
Hope this technical approach helps in better understanding the FSL. Stay Tuned for more such techno-literary pieces!
Kizzy Consulting is a Salesforce Consulting Partner based in Panchkula, India. Kizzy has successfully implemented 100+ Salesforce projects for 100+ clients across sectors like Financial Services, Insurance, Retail, Sales, Manufacturing, Real estate, Logistics, and Healthcare in countries like the US, Europe, Germany, and Australia. Get a free consultation now by emailing us at [email protected] or Contact us.