Tag Archives: sandbox refresh

Sand dunes representing populating sandboxes with data
Data Deployment, Release, sandbox seeding

How to Populate Salesforce Sandboxes With Data

Leave a comment

Providing every developer and admin on your team with their own sandbox for their Salesforce development is an essential aspect of DevOps. To prepare those build and testing environments at the beginning of a project, you need to copy data to them from your production org. In this blog, we’ll discuss 5 ways to populate your salesforce sandboxes with data.

Perform a Salesforce Sandbox Refresh

To get the most current test data in your org, perform a sandbox refresh. This will refresh it with data from your production org. 

Time Limits for Refreshing Salesforce Sandboxes

You can refresh a Full sandbox once every 29 days with metadata and data from production. If you delete a Full Copy, you have to wait until the 29 days are over before you can create a new one.

The refresh interval for a Partial Copy is once every five days. This updates your sandbox with data and metadata from production. Again, if you delete it, you have to wait until the five days are over before you can replace it.

In Salesforce, refresh Developer orgs or Developer Pro sandboxes once a day. Note that this only updates the metadata. You’ll need to seed data into the orgs yourself.

 

How to Refresh a Sandbox in Salesforce

Begin by selecting the sandbox you want to refresh in your list of sandboxes in Salesforce. Click “Refresh,” and review—and if needed, edit—the Name, Description, and Create From values.

Select the type of environment you want. Refer to the table to see the number and type of sandbox licenses in your org. 

Select the data you want to copy. If you’re refreshing a Full Copy, click “Next,” and determine how much of the existing object data you want to copy.

If you’re refreshing a Partial Copy sandbox, click “Next,” and choose a template that determines the data you’re copying. 

You can activate your sandbox immediately after refreshing it by clicking “Auto Activate.”

Clone a Sandbox

If you simply want to recreate an org you’re already using, you can clone it. All its metadata and data will be copied to the new sandbox.

Because the cloned sandbox uses the same license type as the source org, you need to make sure you have that type of license available. 

Use Data Loader and Excel

Data Loader is the native Salesforce data migration tool you can use to seed orgs. You can leverage it to export, insert, update, and delete Salesforce records using the user interface or, if you have Windows, the command line. 

First, prepare the data you want to export from production into your sandbox. Specify the configuration parameters to determine the scope of the data migration. Select the Excel files Data Loader will use to first export the data from production and then into the destination org. Finally, make sure that your field names in the import file correspond exactly to the field names in Salesforce. 

Note that most people find Data Loader to be frustratingly time-consuming, labor-intensive, and prone to error. 

Create a Custom ETL Script

If you’re a developer, you can use an extract, transform, and load script to seed a sandbox in Salesforce. An ETL script might not be the first solution you think of to seed a sandbox, but it can be effective, nonetheless.

The benefits of writing your own script are that you’re not limited by refresh intervals. Nor do you have to use Data Loader. But you do have to invest the time to initially write the script—and then maintain it. 

Use an Automated Data Migration Tool

Use an automated data migration tool from the AppExchange—like Prodly Sandbox Management—to quickly and easily populate sandboxes with data. 

An automated data migration tool has the benefit of minimizing the manual steps involved in the process. On top of that, automation eliminates human error, which prevents frustrating mistakes and do-overs. And like ETL tools, using an automated data migration tool lets you bypass refresh intervals. In short, it’s the easiest, fastest way to prepare your build and test environments for development work.

Leverage Automated Data Migration for CPQ Configuration Data

When using configuration data in apps like Salesforce CPQ, you’ll want to promote changes back up the release chain, as well. In Salesforce, copy data from one sandbox to another further along in the release pipeline with an automated solution. This saves time and prevents errors with migration work and provides you with more time and resources for testing and problem solving. 

Discover the Ease of Prodly Sandbox Management

Prodly Sandbox Management lets you populate up to five sandboxes from production—or any other org—with just a few clicks. Contact us to request a personalized demo. 

A digital bull's eye representing data accuracy
Best Practices

Salesforce Record IDs: When Do They Change?

Leave a comment

Deploying relational data between Salesforce orgs can be challenging when you’re navigating how and when Salesforce record IDs change. If you’re not careful, you may end up with duplicate records… and a lot of extra work.

In this blog, we discuss when record IDs are different and when they remain the same. We also explain how to prevent duplicate data records with Prodly.

Salesforce Record IDs Are Different After Data Migration

Salesforce assigns a unique record ID to each record when you import it into an org. It doesn’t matter whether you import it using manual entry, a simple single-object data loader, or a sophisticated data migration tool like Prodly. 

Salesforce breaks the association between orgs. When you move a data set from one org to another, Salesforce assigns a new record ID to each record in the data set. Think, for example, of when you move data from sandbox to production or from production to sandbox.

Salesforce Record IDs Remain the Same After a Refresh

During a full or partial sandbox refresh, Salesforce copies Salesforce record IDs from production to the sandbox. Because it copies the record IDs, they remain the same. 

Salesforce also copies record IDs when you refresh a Developer or Developer Pro sandbox for standard objects like Products, Price Books, Price Book Entries. It also copies them when you clone a sandbox.

Even when it copies record IDs, Salesforce still breaks the association of the records between orgs. Because the orgs aren’t synced, changes in one org after the refresh will not be reflected in the other.

When you move updated data from a sandbox to your production org, Salesforce assigns a new record ID to each record. If you haven’t taken any precautions against duplication, Salesforce inserts the data set from the sandbox without updating any of the old records in production.

How to Solve the Duplicate Data Problem Manually

Many Salesforce admins get frustrated with the process of deploying data between orgs without creating duplicate records.

Oftentimes, they assign external IDs to each object in a data set to associate the object with a parent object outside Salesforce. If you’ve used this technique before, you know it’s laborious, time consuming, and prone to error.

Prodly Prevents Duplicate Data With Automation

Prodly eliminates this time-consuming manual task with its exclusive automatch feature. When you migrate data, the automatch manager automatically creates an association between source and destination org Salesforce record IDs. It then stores this information in the Prodly app. 

This eliminates the need to manually create and maintain formal external IDs on every record. And that saves you a lot of time and work.

A digital bull's eye representing data accuracy

When you deploy data between orgs, Prodly first checks to see if the source records have a matching record with the same Salesforce record ID in the destination org.

If there isn’t a match, Prodly checks its automatch database to see if the records are the same but the IDs are different. If Prodly doesn’t find a match, it creates a new record. This prevents duplicates during a data deployment.

It’s best to set up the automatch manager when you move data from an existing org to an empty one, from a sandbox to a production org, or after a sandbox refresh.

However, you can still set up automatch during a development cycle. This involves a few extra steps to consolidate data and ensure the automatch manager accounts for all the matching records.

Learn more about setting up the automatch manager and about automatch in general on our help site.

Successful relational data deployment starts with understanding when Salesforce record IDs change and when they’re copied.

Prodly takes matching and changing Salesforce record IDs into account when you deploy relational data with the automatch manager. This solves the problem of duplicate data records without extensive use of external IDs.