Overview 

Configuration data in low-code applications consist of both metadata and reference data. Whether from production to a sandbox or vice versa, Salesforce administrators and developers commonly deploy project metadata using change sets and deploy their reference record data (such as custom objects and settings) using data loader and spreadsheets. Release empowers you to deploy both metadata and reference data in a single deployment, without change sets, Data Loader, or spreadsheets. Release deploys the configuration information in the data, as well as the data records themselves, with a unique, intuitive user interface that is certain to ease the pain you’re experiencing.

Org-to-Org Deployment Building Blocks 

Salesforce environments, deployment templates, data sets, deployment plans, deploy, and deployment results are the building blocks of org-to-org deployment.

The main building block of org-to-org deployment is the Data Set. During deployment, Release follows the instructions in the data set to determine which Objects, Records, and Fields to deploy. For convenience, you can group multiple data sets in a Deployment Plan and execute deployment for your entire low-code app with a single click.

Because low-code apps tend to contain many objects with complex relationships, Prodly has gone to great lengths to develop and provide pre-built Deployment Templates for apps such as Salesforce CPQ and Salesforce Field Service. Each template contains a deployment plan and data sets specific to the app for quicker implementation. To get started, you import the deployment plan and data sets from the template, then further customize them to meet the specifics of your use case. You can also create data sets, deployment plans, and even deployment templates of your own from scratch.

At deployment time, environment connections and the deployment flow control data deployment. The key is Release’s centrally-controlled deployment architecture.

Release’s Centrally-Controlled Deployment Architecture

For the Prodly Release service to deploy data between orgs, you establish connections between the Prodly Release service and the orgs responsible for control, schema, data source, and data destination, and define their purposes:

• During the Prodly managed package installation and configuration, you established the control org environment (the org that houses the Prodly managed package, stores your data sets, and controls deployment).
• Anytime before deployment, you establish additional environments (connections to different orgs) from the Environments page within the Release tab.
• During data set creation and at deployment, you define the purpose(s) each connection serves for your particular use case.

To initiate the deployment, you use the deployment flow to specify the source and destination orgs, the data set or deployment plan, and any metadata to deploy.

Workflow 

For maximum flexibility and versatility, you build and operate your org-to-org deployment environment in this order:

1. Start by installing the Prodly managed package in the org to use as your control org.
2. Complete Onboarding with your CSM and Account Manager.
3. Specify the Salesforce environments you intend to deploy to/from.
4. Install deployment templates and/or create reusable deployment plans and data sets.
5. Customize data set elements, containing parent and child relationships, objects, and fields.
6. Deploy the data sets to copy all of your related CRM data from source to destination.
7. Monitor the deployment progress.
8. Verify the deployment results.
9. Optionally save a snapshot of your reference data to your VCS.

Scope 

The AppOps org-to-org deployment feature is a tried-and-true product that has been in commercial use for several years (formerly as Moover). The scope of the current release includes deploying:

• Data and Metadata between any two Salesforce orgs you have permission to access.
• Any reference and transaction data is describable in a data set.
• Most standard picklist metadata (as part of a data set). 
• Most Salesforce data types. 
• Many Salesforce metadata types.