Build Datasets uses a source Salesforce org to download a connected set of data records as XML files to your local machine. A dataset is a related group of records — not metadata — and it is the raw material you later push to another org with Migrate Datasets. When you build a dataset, all of the internal relationships between records are preserved, so the hierarchy stays intact when it is migrated. This is how you populate sandboxes with test data, back up relational data, or stage records for an org merge.
Getting started
Select the Deployment Arrow between two connected Snapshots and the Options Menu displays the available commands; you can also right-click the Deployment Arrow to see them in a popup. The third submenu contains Build, Migrate, and Manage Datasets. If you do not see these options, the arrow is probably connected to a Developer Project — those contain no actual data and cannot be used as a source for building a dataset.
Choosing a dataset and template
The first tab of the Build Datasets dialog lets you select the dataset and template you want to work with. If you are moving records associated with a managed package, check the Prebuilt Templates menu for help — Salesforce CPQ, Health Cloud, and Government Cloud all have custom templates.
Selecting parent records
The next tab lets you select the parent records to include, drawn from the source org. You can select:
- All records
- A subset of records by name
- A subset of records using a complex filter
- Records returned by a SOQL query you write by hand
You can also limit the total number of downloaded records, which is handy for grabbing a random subset for acceptance testing or application development.
Selecting child objects
The next tab lets you select the connected child objects for each parent. When the dataset is created, the selected parent records are loaded first, followed by all the children connected to that parent. You can specify multiple child objects in a hierarchy, and the relationship field used to associate each parent and child is shown in parentheses — for example OpportunityLineItem (OpportunityId). The internal relationships between parent and child are always preserved when the dataset is migrated.
Loaded fields
For each object you choose which fields to load. Two buttons help you here:
- Child Record Limits (upper right) — add a filter or limit the number of records for the selected child object.
- Estimate Dataset Size (lower right) — calculate the estimated number of records and the total size of the dataset before it is actually created, so you can right-size the extraction.
Loaded fields do more than pull data: Snapshot also uses them to identify matching records in the destination org during migration. If a source record matches a destination record, that record is updated; if it does not match, a new record is created. Snapshot automatically selects the most common matching fields, but you can add your own — for example, to match Accounts by Name and BillingCity later, make sure both Name and BillingCity are loaded now.
Beneath the dividing line you will see external references to other objects in the destination org. For example, selecting Opportunity objects shows an external reference to Campaigns, because the Opportunity object contains a CampaignId reference field. Snapshot connects external references to matching destination objects automatically when the dataset is migrated, and you can specify additional fields needed to match them.
Building the dataset
On the next tab, enter a name for the new dataset and click Build Datasets to start the download. If you pick an existing dataset name from the menu, that dataset is replaced. All download results are listed in the pane at the lower right.
The XML files are saved in the datasets folder, next to the workspaces folder in the Snapshot file system. Datasets are globally available for migration to any destination org — any source org can build a dataset, and any dataset can be migrated to any destination.
Scheduling
The last tab lets you build the dataset at a specific time in the future or as a recurring event. A scheduled build automatically replaces the current dataset by name. Note that, unlike Snapshots, datasets are not maintained in a time series.
Tips for a clean hierarchy
Select the parents first, then the children. Try to use only parent objects and avoid child objects where you can, and do not try to rebuild your conceptual data model in the object hierarchy — Monarch figures out all the relationships between objects automatically. Focus on simply getting the desired records into the dataset. Child objects should be used only to limit the selected records to a related parent.
If you build a complex hierarchy that mirrors your data model, two problems can occur. Child objects can end up in the dataset multiple times (during migration each record is still migrated only once), and if a parent record fails to migrate because of an error, its child objects — and their children, and so on — cannot migrate either.
Please, remember that effectively using Metazoa Snapshot to manage your Salesforce data requires a solid understanding of your data structure and relations. If you need further assistance, our support team is ready to help.
Video
Links
Snapshot Best Practices: Salesforce Relational Data Migration