This table contains Prodly terms and their definitions. The terms are initially sorted alphabetically. Click any heading to sort the table by that column.
| Term | Definition | Product | Category |
|---|---|---|---|
| Agile development | 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. | All | General |
| Baseline results | Baseline results are an initial snapshot of values (results) for the specified object fields, stored in the test case. Test compares the stored values to the values in future test runs. | Test | Test cases |
| Branch | A branch is a container within a VCS repository that holds a copy of your data so you can edit that data without altering the original data. | Release | Version control |
| Centrally-controlled deployment | Centrally-controlled deployment allows you to install Release once in a central Salesforce org and control all deployments from there. Establish connections to all of your orgs and deploy between them, with any org being a source or destination based on your need at the time. | Release | Org-to-org deployment |
| Change management | Within a computer system, change management is the controlled identification and implementation of required changes. In the context of Release, change management is the systematic process of determining, approving, testing, and implementing changes to the configuration data in your Salesforce orgs. | Release | General |
| Configuration data | Configuration data for low-code apps is the reference data and metadata you create during app configuration to define your system. | All | General |
| Connection | Each Prodly connection is a bridge between the Prodly service and your Salesforce control, schema, source, and destination orgs, which gives the service limited access to your orgs. Connections are created when a managed environment is added to the environment page within Release tab. | Release | Org-to-org deployment |
| Control org | Your control org is the org where you install the Prodly managed package. For org-to-org deployments, it is where you build your data sets, store your data sets, execute deployments, and manage user security parameters. The control org is the key to Release’s centrally-controlled deployment architecture. For version-controlled deployments, it is where your source of truth data resides and where you maintain managed orgs via the management board. | Release | Org-to-org deployment |
| Data set | A data set is a reusable set of reference data deployment instructions Release uses to determine which objects, records, and fields to copy during deployment. A data set identifies the structure of the data Release deploys, not the data in the structure. | Release | Org-to-org deployment |
| Data set element | A data set element is a portion of your data set containing deployment instructions specific to a single Salesforce object. Each data set element identifies a deployment object, element details, object fields, field properties, parent relationships, and child relationships. | Release | Org-to-org deployment |
| Data set element chain | Each data set consists of a data set element for each deployment object in the data set, organized as a data set element chain. The chain defines the direction Release traverses your data during deployment. | Release | Org-to-org deployment |
| Data set relationship | A data set relationship is a parent-child relationship between two data set elements. | Release | Org-to-org deployment |
| Deploy | Org-to-org deployment means to update data in a destination org with data from a source org directly, not including handling deletes, using a deployment plan or data sets. Data does not pass through or automatically get captured by the VCS, but you can manually capture snapshots of the data for versioning or backup. Version-control deployment means to update data in a Salesforce org with data from the VCS branch associated with the org, including handling deletes, without the need for a deployment plan or data sets. | Release | General |
| Deployment object | A deployment object specifies the Salesforce object to use as the basis of a data set element. | Release | Org-to-org deployment |
| Deployment plan | A deployment plan is a reusable set of instructions that group data sets and define the order in which to deploy them. | Release | Org-to-org deployment |
| Deployment templates | Deployment templates are JSON-formatted files that contain the deployment plan and data set information Release needs to recreate the deployment plans and data sets. | Release | Org-to-org deployment |
| Destination org | A destination org is an org that receives the source data during deployment. | Release | Org-to-org deployment |
| Destination schema org | A destination schema org is an org containing the schema the data set editor uses as the basis for controlling data deployment in the destination org. | Release | Org-to-org deployment |
| Element details | Element details are data set element settings that control various aspects of deployment of the Salesforce object. | Release | Org-to-org deployment |
| Field properties | Field properties are data set element options for adjusting destination fields during deployment. | Release | Org-to-org deployment |
| Function | Function specifies the type of functional test to run. For example, Calculate uses the Salesforce CPQ Calculate API to retrieve baseline values from the object fields specified in the test template. | Test | Test cases |
| Low-code app | 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. | All | General |
| Managed Environment | Each Prodly managed environment is a bridge between the Prodly service and your Salesforce control, schema, source, and destination orgs, which gives the service limited access to your orgs. Prodly uses industry-standard refresh OAuth (for authorized access) and JWT OAuth (for preauthorized access) to eliminate the possibility of exposing your login credentials. | Release | Org-to-org deployment |
| Managed org | A managed org is a Salesforce org you place on the Release management board to control data deployment. For orgs you also place under version control, Prodly creates an associated VCS repository branch. | Release | General |
| Merge | Merge means to integrate changes made in a branch into its parent branch. | Release | Version-control deployment |
| Metadata | Metadata is a type of configuration data you create during app configuration that influences information architecture and look and feel of your environment. | All | Salesforce |
| Object fields | Object fields are the individual fields in the data set element’s Salesforce object. Release functionality allows for inclusion of all fields or individual fields you select. | Release | Org-to-org deployment |
| Org | An org is any production, developer, sandbox, or scratch environment within a Salesforce customer account. | All | Salesforce |
| Org-to-org deployment | Org-to-org deployment means to update data in a destination org with data from a source org directly, not including handling deletes, using a deployment plan or data sets. Data does not pass through or automatically get captured by the VCS, but you can manually capture snapshots of the data for versioning or backup. | Release | Org-to-org deployment |
| Prodly managed package | The Prodly managed package is the software you install in your Salesforce org that provides the user interface to the Prodly products. | All | General |
| Prodly service | The Prodly service is the backend portion of Prodly platform that runs on a server in the Prodly cloud and performs the data deployment. | All | General |
| Reference data | Reference data is a type of configuration data you create during app configuration that is stored as record data within the app’s objects. | Release | Org-to-org deployment |
| Record matching method | The record matching method tracks and determines what Release does during deployment when source records already exist in the destination org. | Release | Org-to-org deployment |
| Regression testing | Regression testing is a testing practice that ensures an app still functions as expected after any changes, updates, or improvements to the reference data, code, or environment. | Test | Test runs |
| Repository | A repository consists of a master store of data (master branch) and other branches you use for feature development and testing. The master branch contains the data for all objects you place under version control. | Release | Version control |
| Roll back | In the context of version control, roll back means to revert changes to a previous version. | Release | Version control |
| Root element | A root element is a special instance of a data set element and the first element in a data set. The Salesforce object you choose as the deployment object in the root element becomes the starting point from which all other objects and fields to copy stems. Each data set contains exactly one root element. | Release | Org-to-org deployment |
| Save to branch | In the context of version control, save means to replace data in a VCS branch with data from the Salesforce org associated with the branch, including handling deletes. | Release | Version control |
| Schema | A schema is set of related objects in an org. The complete structure of the database. Just the structure, not the data in the structure. A schema defines the relationships between objects in an org or app. | Release | Org-to-org deployment |
| Schema org | A schema org is an org containing the schema the data set editor uses as the basis for building data sets in the control org. All objects in a data set must also exist in the source and destination org schemas. | Release | Org-to-org deployment |
| Source data | Source data is records in an org’s objects that Prodly Release uses as the data to copy during deployment. | Release | Org-to-org deployment |
| Source org | A source org is an org containing the source data to deploy. | Release | Org-to-org deployment |
| Test case | A test case specifies parameters for evaluating the accuracy of a particular feature during future test runs. Each test case consists of a test template (which specifies the objects and fields to test), the functionality to test, the ID of the Quote record to test, and baseline results (created on Save). | Test | Test cases |
| Test run | A test run specifies a set of test cases and includes the results of running the test cases, indicating whether actual results differ from expected results. | Test | Test runs |
| Test run results | Test run results provide a snapshot of values (results) for all test cases in the test run at the time you executed the test run. Test compares the values in the test run results to the values in the baseline results. | Test | Test runs |
| Test template | A test template specifies a list of fields (from one or more objects) for future use by test cases. You can use a template as the basis for multiple test cases. | Test | Test templates |
| Upsert method | See record matching method. | Release | Org-to-org deployment |
| Version control | Version control or revision control is the process of capturing snapshots of your configuration data at various moments in time, allowing you to track, record, and revert changes. | Release | Version control |
| Version-control deployment | Version-control deployment means to update data in a Salesforce org with data from the VCS branch associated with the org, including handling deletes, without the need for a deployment plan or data sets. | Release | Version-control deployment |
| Version control system | A version control or revision control system is software you use to keep track of changes you make to your data and allows you to revert changes to a previous known state. | Release | Version control |