Field Service Lightning (FSL) is an automated system for coordinating field operations, including scheduling service appointments, dispatching mobile workers and equipment, and tracking vehicle locations, product stock, and appointment status. Agents can create work orders as customer service calls come in. The dispatcher schedules appointments, optimizing them according to who has the right skills, is carrying the right parts, and is in the right location. The mobile resources (or technicians) complete the service appointments and close out the work orders. Field Service has three main parts that work together:
Core Field Service features
Scheduling and optimization from a managed package
A mobile app for the mobile workforce
All users need the Field Service Standard user permission to access standard field service features. Most user licenses already include this permission. You need special permission set licenses to view the dispatcher console, use the mobile app, or be included in scheduling optimization.
Field Service is centered around work orders. A work order is a specific customer request for field service. After you create a work order, dispatchers assign it to service appointments and resources.
For more information about how FSL works, we suggest completing this trail on Trailhead.
When configuring a data deployment, you must take into consideration that Gearset data loader detects referenced objects and brings related records into the deployment, but this referencing only works in one direction. After clicking NEXT on the first configuration step of the data deployment, you can pick for each object a field to use for matching existing records. The ID field must be specified as an 'external ID' or 'ID lookup' field within Salesforce.
Let’s see some suggestion specific to FSL data deployment:
1) Deploy Mobile Resources
Overview
A Service Resource represents a mobile worker User.
Skills are assigned to resources by a Service Resource Skill record.
A Service Territory represents a geographic or functional region in which field service work can be performed.
A Service Territory Member record associates Services Resources to Service Territory.
Operating hours represents the hours in which a service territory, service resource, or account is available for field service work.
A Location represents a warehouse, service vehicle, work site, or other element of the region where your team performs field service work.
Locations are assigned to Service Territories by a Service Territory Location record.
Data deployment plan
As usual in a data deployment configuration, we need to select all the 'leaves', which are the objects we're interested in that don’t have any other object pointing to them. In this case we will select as top-level items Service Resource Skill, Service Territory Location and Service Territory Member.
For this example, we will assume that there are no resources not assigned to a territory with a Service Territory Member, or no location not assigned to a territory with a Service Territory Location, so we will select these objects only at the next step of the configuration, as related objects. If this was not the case, Service Resource and Location should be added to the top-level items. Likewise, we will assume that all Operating Hours are linked to a territory, and we will select them only as related objects.
Common errors
Data deployments cannot create new users, and only the option Look up existing records will be available (shown above). Before your data deployment, make sure you have all the Users related to Service Resources already in your target, or you will get the REQUIRED_FIELD_MISSING error message.
2) Deploy basic objects related to Work Order
Overview
A Work Order is a specific customer request for field service.
Agents can create Work Orders from Work Type templates. Work Types are easy templates you can create for common jobs your mobile workforce performs. Having a Work Type to keep track of everything needed to complete the request is helpful but not necessary.
Work Order Line Items are smaller tasks needed to complete the original request. Work Order Line Items function the same way Work Orders do, but they’re associated with a parent Work Order.
You can specify the required parts (Product Required) and skills (Skill Requirement) to do a job, so the right mobile resource is assigned the task. Your mobile workforce may need to use parts or tools from their van or utility box (Location).
A Product Item represents the stock of a particular Product at a particular Location.
Data deployment plan
For this deployment we will select as top-level items Product Required, Skill Requirement and Work Order Line Item. This selection will bring the related Work Orders at the next step of the configuration. However, not all the Work Orders have a required Skill, Product or Line Item. For this reason we need also to select the Work Order as a top-level item. Finally, we select Product Item, bringing the related Product and Location at the next step.
We will assume that with this deployment we want only to bring the Locations that have stock of a Product. So, we will select Location, Product and Work Type only at the second step of the configuration. Many objects don't have an external ID, but they have an auto-number ID field generated by Salesforce. This field is managed by Salesforce, and cannot be modified or used as external ID for upsert. For all the objects that didn't have an External ID we created an External ID field (Unique_ID, Text) and populated this field by simply copying and pasting the randomly generated field assigned by Salesforce.
Common errors
(1) DUPLICATE_VALUE error with WorkOrder seems related to this known issue https://trailblazer.salesforce.com/issues_view?id=a1p3A0000008mgRQAQ and unfortunately it does not have a fix.
Removing unique attribute to the custom field will not work
Leaving the field empty as suggested on Salesforce is not possible when this field is used for upsert.
Unfortunately the only workaround is to delete the Work Type record related to the Work Order that we are deploying. Then add it to the deployment plan as a related object.
(2) INVALID_FIELD error with Skill Requirement and Product Required seems to be related to the polymorphic lookup fields, which can reference multiple objects. You might see this error if one of the objects referenced is not included in the deployment or is un-deployable.
For example, Skill Requirement might need Work Order, Work Order Line Item, Work Type, and Job Profile to be part of the deployment, in order to succeed:
(3) INVALID_FIELD_FOR_INSERT_UPDATE:Unable to create/update fields: Product2Id. for Order Item
According to the Object Ref doc, the properties of the field ProductID are: Create, Filter, Group, Nillable, Sort.
Update is not allowed, so it is unfortunately impossible to insert new Product Items and update the existing ones in the same data deployment. All product Items need to be deleted and redeployed. Alternatively, it should be possible to run a partial deployment first, where all the existing Product Items will fail to deploy, but the new ones will be deployed correctly. Then run the same deployment again, deselecting ProductID at the first step of the configuration.
This would update existing Product Items (but not the ProductID field).
3) Deploy work orders from a Maintenance Plan
Overview
A Maintenance Plan lets you define the maintenance schedule for one or more Assets, and usually it automatically generates a batch of Work Orders for future maintenance visits.
An Asset represents a specific purchased or installed Product. Each customer’s purchased/installed product would be tracked in its own Asset record that’s linked to the Product object with a lookup. Every Asset needs to be linked to an Account, a Contact, or both.
Maintenance Plans are often used to carry out terms in a Service Contract.
You can associate a Maintenance Plan with one or more Assets by creating Maintenance Assets, which are records that represent the relationship between the Asset and the Plan.
In case of replacement/upgrade of an Asset, Asset Relationship represents the link between the old and new Asset for tracking purposes. Asset relationships appear in the Primary Assets and Related Assets related lists on Asset records:
Primary Asset appears on the replaced Asset record, and the record contains the new Asset.
Related Asset appears on the new Asset record, and the contains the Asset that was replaced.
Data deployment plan
This deployment is similar to the one in the previous section, except for the object related to the scheduled maintenance. We will select as top-level items Product Required, Skill Requirement, Work Order Line Item, Work Order, Product Item, Maintenance Asset and Asset Relationship. As before, if we have a new Asset that does not have a Maintenance Plan or a Work Order, we also need Asset as top-level selection. The data tool will follow the lookup relationship and bring to the deployment all the other objects in the picture.
Common errors
To keep your records clean, please note that a Maintenance Plan might have active the option to auto-generate Work Orders. This option might cause duplicate work orders (one from the deployment, and one auto-generated), but it can be deactivated:
For the same reason, if Auto-Generate Service Appointment is selected for the Work Type associated with the Maintenance Plan, new Work Orders might also create automatically Service Appointment records.