VP of Marketing
Hayley Coxon is the Vice President of Marketing and Revenue Operations for Prodly and accidental admin since 2010. You can find her on LinkedIn.
Reference data makes the implementation of Field Service Lightning (FSL) complex. That’s why Prodly released the Prodly Toolkit for Field Service Lightning to offer admins a streamlined, hassle-free data deployment environment.
With the release of the Prodly Toolkit for Field Service Lighting, we’re offering FSL admins the same hassle-free deployment that we’ve provided to admins of Salesforce CPQ.
Salesforce CPQ’s product catalog, price rules, and discount rules are easily recognizable as objects containing reference data, also referred to as configuration data. However, with Field Service Lightning, it’s no always so clear cut. What objects require updates via reference data deployment, and how do you make it happen?
Reference data defines the set of permissible values to be used by other data fields. It’s used amongst other things in Salesforce applications like Salesforce CPQ, Billing, Advanced Approvals, and Field Service Lightning. In these applications, configuration data allows users to configure their Salesforce environment to their business’s needs without having to code.
The ability to extend the usefulness of Salesforce to meet the unique challenges of your business through clicks, not code, is an extremely valuable selling point. A Salesforce admin may have little or no experience with developing on the Salesforce platform. However, they can still be able to keep the business’s marketing, sales, and customer success initiatives on Salesforce up-to-date and running smoothly.
So what does that mean for Field Service Lightning?
The initial implementation of Field Service Lightning is a complicated process. Many businesses use an implementation partner to ensure the application is set up properly.
First, the implementation partner collects data from existing systems; then they deploy it to a Salesforce sandbox org for testing. Once they’ve confirmed the app is working, it’s deployed to production. Finally, employees can use it to deliver a fast and intuitive service experience to customers.
You need to review and update reference data fairly regularly to maintain a useful data set. Operating hours may change seasonally, for example, or services may be added, changed, or removed.
However, not all objects within Field Service Lighting contain configuration data. Objects that contain transaction data like service reports and work orders go through a different process during the everyday use of Field Service Lightning.
Of the 54 objects used in Field Service Lightning, 27 contain configuration data. The following 20 are most typically updated during a reference data deployment:
You can see a full list of Field Service Lightning objects and data types in our Prodly Field Service Lightning Reference Data Deployment Guide.
The Salesforce method of clicks, not code allows people without developer experience to manage and update Field Service Lightning. However, the traditional method of using a data loader and spreadsheets is by no means easy.
With a data loader, admins are required to manually remap the lookup relationships between the records and destination org. This is a tedious process that’s prone to errors.
Moving data between a developer org or QA to production involves repeating this process several times. Failing to test changes can mean a breakdown in production, which can mean angry customers, disconnects, and lost business.
Our new Prodly Toolkit for Field Service Lightning makes Prodly, our productivity-enhancing reference data deployment tool, even easier to use for FSL. With data set templates to simplify the deployment process, our complete deployment guide, and expert support, we’ve made Field Service Lightning as easy to use for admins as it is for customers.