Overview: Field Service Lightning

These help topics guide you through org-to-org deployment of your Field Service Lightning (FSL) reference data using Prodly AppOps Release. Prodly provides pre-built org-to-org deployment toolkits to assist with reference data deployment in your low-code apps. Each toolkit contains customizable AppOps Release data sets and a deployment plan as templates, which provide AppOps Release the deployment instructions it needs for successful org-to-org deployment. The templates are available in the Prodly User Community.

An org-to-org deployment copies reference data directly from one Salesforce org to another Salesforce org, bypassing the version control functionality.

Reference data is data you create during app configuration that is stored as record data within the app's objects.

Low-code apps store much of their configuration setup in data records, called reference data, in the app's objects, rather than as code or metadata.

A data set is a reusable set of reference data deployment instructions AppOps Release uses to determine which objects, records, and fields to copy during deployment. A data set identifies the structure of the data AppOps Release deploys, not the data in the structure.

A deployment plan is a reusable set of instructions that group data sets and define the order in which to deploy them.

Deployment templates are JSON-formatted files that contain the deployment plan and data set information AppOps Release needs to recreate the deployment plans and data sets.


Each data set in the toolkit is a logical grouping of FSL reference data. You can deploy the data sets one-by-one manually or use the deployment plan to deploy all the data sets with a single click. Because every implementation is unique, data sets are editable so you can make changes to suit your implementation needs.

What's Reference Data?

In any low-code Salesforce app, reference data is data you create during app configuration that is stored as record data within app's objects. Because the reference data is stored as record data and not as code, you cannot deploy the data with change sets or other metadata tools. But deploying the data between Salesforce orgs using a data loader and spreadsheets can be very difficult and time consuming because low-code reference data is highly relational.

Therefore, creating and maintaining an agile development process for FSL using traditional tools is very difficult. Most admins are too time-constrained to follow the best practice of creating and maintaining reference data in a development sandbox, then deploying to a QA sandbox, then to a UAT sandbox for testing and training, and eventually to the  production org.

Agile development is an iterative process of plan, develop, and deploy used to rapidly respond to ever-changing client needs while ensuring accurate prototyping through the collaboration of all internal stakeholders.


Prodly specifically designed AppOps Release and the deployment toolkits to handle the interrelational nature of low-code app reference data. There are many factors to consider, including the need to deploy data in a specific order to maintain the relationships. The toolkits help you carefully analyze your data to determine the best approach and sequence of deployment events.

Why VEID?

AppOps Release does not require the time-consuming process of adding Salesforce external IDs to every object just to maintain the integrity of the relationship IDs in the destination org post-deployment. Instead, AppOps Release provides powerful upsert features which take the standard Salesforce upsert functionality to a whole new level:
  • Virtual external ID (VEID) - Allows AppOps Release to track and manage the relationship IDs for you.
  • Composite external ID (CEID) - Allows you to concatenate fields in the object to create composite IDs, rather than rely on traditional Salesforce external IDs.
  • Formal external ID (FEID) - For clarity, Prodly refers to standard Salesforce external IDs as FEIDs to avoid confusion.
Prodly strongly recommends using VEID because, even with concatenated composite IDs, records in some of the FSL objects are not guaranteed to have unique IDs. The data sets in the toolkit use the VEID upsert functionality and assume your destination org does not initially contain any FSL .
Warning If you are starting in the middle of a development cycle and there is existing data in your destination org that was entered by a method other than a sandbox refresh or sandbox cloning (such as a data loader or manual entry), consult with Prodly to determine the best approach to moving forward.


      Current topic: Jump to Top    Next topic: Deployment Checklist

© Copyright 2020 Prodly, Inc. All rights reserved. Prodly, AppOps Release, and AppOps Test are trademarks of Prodly, Inc., as are other names and marks. Salesforce and other names are trademarks of salesforce.com, inc., and are used here with permission. Other marks and names appearing herein may be trademarks of their respective owners.