Here are some key concepts to help you grasp the power and fine-grained control Release offers. Your understanding of these concepts is essential to successfully deploying only the specific data you desire to deploy.
In the data set editor Tabs view, you select objects from the Parent Relationships and Child Relationships tabs to create a chain of data set elements that define the direction Release traverses your data during deployment. Which objects link to which other objects is totally under your control and what you choose is vitally important for identifying which records to deploy and in which order.
For example, in the following diagram, Release deploys the green records when you select Account as the root element in the data set, Contact from the Child Relationships tab of the Account element, and Case from the Parent Relationships tab of the Contact child element. Release includes the blue records only when you also select Contact from the Child Relationships tab of the Case child element.
Understanding relationship direction allows you to avoid including additional extraneous children of a child’s parent. This concept also applies to extraneous parents.
Conversely to relationship direction, ignore relationship constraint allows you to deploy all records in an object regardless of parent/child relationships. The method is similar to the concept of an outer join. Control this functionality with the Ignore Relationship Constraint property on the Element Details tab in the data set editor Tabs view.
Release allows you to use query filters to control which records to deploy. Release’s intelligence also recognizes and deploys records that are required because of related lookups even when the records don’t meet your query filter criteria. However, you can instruct Release to override its intelligence and deploy only the records that meet your query filter criteria. Control this functionality with the Enforce Strict Query Filter property on the Parent Relationships tab in the data set editor Tabs view.
This feature allows you to insert the lookup ID into the destination org record, rather than deploy the parent record data. Control this functionality with the Copy Relationship Value property on the Object Fields tab in the data set editor Tabs view.
Copy Relationship Value only works when the parent record exists in the destination org. Errors occur when the parent record does not exist in the destination org. An example of a valid use case is a lookup to User records, because User records are generally present in both the source and destination orgs.
In any given data set, each Salesforce object you select for inclusion from the Parent Relationships and Child Relationships tabs of the data set editor exists in exactly one data set element regardless of how many times you pick that object from various lookup relationships. There are use cases though that need to skip processing farther down the data set element chain (that you previously identified on the Parent Relationships and Child Relationships tabs) for some of the lookups. For example, in Salesforce CPQ, product records contain separate relational lookup fields for required product options and optional product options.
In this example, to save time and space when copying test data to a sandbox, you can skip deploying the discount schedules, price rules, and more for the optional products by selecting the Skip Relationship Processing option on the parent lookup for the optional product options on the Parent Relationships tab in the data set editor Tabs view.