This table contains Prodly terms and their definitions. The terms are sorted alphabetically.
| 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 |
| Change types | Change types are defined templates in Prodly that centralize all necessary inputs for setting up a development environment. This allows users to quickly create pre-configured environments with specific packages, metadata, and data sets for focused development and verification of changes. | Release | General |
| Compare | Compare refers to the process of visually identifying differences in metadata between two environments. This feature highlights whether components exist in only the source, only the destination, or in both with differing values, helping users understand and select changes for deployment. | Release | Org-to-org deployment |
| Compliance center | The compliance center is a Prodly feature that allows users to track and document changes to Salesforce data and reference data. It enables the monitoring of environments for configuration changes and the generation of comprehensive audit reports for compliance purposes. | Compliance Center | Monitoring |
| 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 bundle | A deployment bundle is a package that contains metadata and/or data, saved at the time of creation. This allows users to deploy the exact same package across multiple environments without needing to reselect components or risk deploying unplanned changes. | Release | Org-to-org deployment |
| 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 |
| Development environment | A development environment is a designated environment where development work is performed. These environments can deploy to other development environments and the first stage of any pipeline, and by default, include Developer Sandboxes, Developer Pro Sandboxes, and Scratch Orgs. | Release | General |
| Element details | Element details are data set element settings that control various aspects of deployment of the Salesforce object. | Release | Org-to-org deployment |
| Environment access control | Environment access control is a feature that allows administrators to customize and manage user access to managed environments. This involves configuring permissions at various levels, including permission sets, organization-wide defaults, and sharing rules, to ensure appropriate visibility and control over deployment environments. | All | General |
| Event control | Event control is a feature that allows users to temporarily deactivate specific events (such as triggers, validation rules, or workflows) associated with a Salesforce object during a data deployment. This ensures a smoother deployment process by preventing unintended automated actions, and events are reactivated once the deployment is complete. | 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 |
| Full data preview | Full data preview is a feature on the Deploy page that allows users to review the data set or deployment plan before execution. It provides a breakdown of all root records, indicating whether they will be inserted, updated, or deleted in the destination, and allows users to select which records to include in the 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 |
| Integration | An integration is a connection between Prodly and external work management or version control tools, such as Jira or GitHub. These integrations streamline workflows by allowing Prodly to interact with and leverage the functionalities of these connected systems. | Release | General |
| Invocations | Invocations is a feature that allows users to execute custom Apex code within any of the Salesforce organizations involved in a deployment. This provides fine-grained control for automating complex setup or teardown actions before or after data set or deployment plan execution. | Release | Advanced automation |
| JWT OAuth Flow | JWT OAuth Flow is a secure authentication method used to connect to Salesforce environments without requiring repeated interactive logins. It utilizes a JSON Web Token (JWT) and a certificate to sign requests, making it particularly useful for server-to-server integrations and after sandbox refreshes. | All | General |
| 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 |
| Metadata bundle | A metadata bundle is a pre-configured package of metadata components that can be saved and reused for future deployments to various environments. It streamlines the deployment process by eliminating the need to manually run comparisons each time, allowing users to quickly select and deploy a predefined set of metadata. | Release | Org-to-org deployment |
| Metadata dependencies | Metadata dependencies are relationships between different metadata components, where one component relies on another to function correctly. Prodly’s Dependency Check feature helps users identify these required components before deployment to prevent errors and ensure successful, reliable deployments. | Release | Org-to-org deployment |
| Metadata filters | Metadata filters are a customizable setting in Prodly that acts like a list view for metadata deployments, allowing users to specify and narrow down the types of metadata components to load and compare between environments. This improves performance by focusing on relevant components and streamlines the identification of specific changes. | Release | Org-to-org deployment |
| Metadata snapshot | A metadata snapshot is a captured state of an environment’s metadata at a specific point in time. These snapshots can be run automatically on a daily or weekly basis in Prodly, allowing for faster metadata comparisons between Salesforce organizations. | Release | Org-to-org deployment |
| Monitored environment | A monitored environment is a connected environment within Prodly that has a Monitoring Rule assigned to it, allowing users to track and report on changes made within that specific environment. Only managed environments can be monitored, and users require read access to the environment to set up monitoring. | Compliance Center | Monitoring |
| Monitoring rules | Monitoring rules are a configuration within Prodly’s Compliance Center that defines which specific data and objects users want to track for changes. Once created, a Monitoring Rule can be assigned to one or more Monitored Environments to generate reports on those tracked changes. | Compliance Center | Monitoring |
| Next-gen data processing | Next-gen data processing is an enhanced data processing logic in Prodly designed to improve the performance, precision, and accuracy of deployments. Users can activate this feature via a toggle in settings, and it requires a specific custom permission set for full functionality. | Release | Org-to-org deployment |
| 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 |
| Pipeline | Pipelines provide a structured way to control how deployments move between different environments. They ensure consistency, enhance visibility, and improve governance by defining stages that deployments must follow. Only Prodly Admins can create and edit pipelines. | 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 |
| Query filter | A query filter is an optional SOQL WHERE clause in Prodly that allows users to specify criteria for selecting a subset of source data records for deployment. This helps in seeding test data or copying only relevant information between Salesforce organizations, especially useful for managing data in partial sandboxes. | Release | Org-to-org deployment |
| 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 |
| Releases | Releases (bundles of Bundles) are containers for multiple Bundles that you want to deploy together in a coordinated and trackable way to simplify org-to-org deployments and improve governance. | 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 |
| Sandbox seeding | Sandbox seeding is the process of populating a Salesforce sandbox environment with data from a source environment, often production. This allows users to create realistic testing or development environments with relevant data without affecting live production systems. | 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 |
| Subcomponent deployments | Subcomponent deployment is a feature that allows users to deploy specific, smaller parts of a metadata component (such as profiles, permission sets, or page layouts) without needing to deploy the entire component. This helps prevent unintended overwrites and enables the deployment of only completed or necessary changes. | 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 suites | Test suites are a collection of one or more Test Cases, allowing users to logically group related tests for more efficient execution and management. Test Suites can be scheduled to run automatically to identify any newly introduced defects within a system. | Test | Test cases |
| 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 |
| Transformations | Transformations is a feature that enables the deployment of source organization data to different objects, record types, fields, picklist values, and relationships in the destination organization. This allows for flexible remapping and restructuring of data during the deployment process. | Release | Org-to-org deployment |
| Upsert method | See record matching method. | Release | Org-to-org deployment |
| Validate data | The validate data process simulates a data deployment to show which records would be processed without actually deploying them. This validation provides insight into the records involved but does not predict specific deployment errors or the exact record handling operations (insert, update, upsert) in the destination. | Release | Org-to-org deployment |
| Validate metadata | The validate metadata process simulates a metadata deployment by calling Salesforce’s own validation routines. This allows users to check for potential errors and confirm the deployability of selected metadata components before actually deploying them to a destination environment. | Release | Org-to-org deployment |
| Validation tests | Validation tests are pre-deployment checks in Prodly that specify which Salesforce Validate Change Set routines to run on metadata. These tests ensure the deployability of components and can range from running no tests to executing specific local tests or all tests, especially critical when deploying Apex classes or triggers to production. | 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 |