At the moment our developer workflows uses Sandbox as development branches and from Sandboxes developers push straight to production. We have now additional requirements:

  • Have a QA environment
  • Have a DEMO environment which replicates production

For the first issue, we could simply force all developers to push from branch instances to QA instance and then to production, while for DEMO environment we could simply "refresh" a sandbox.

The problem we have, however, is that we would need to preserve the data in the instances, while upgrading the metadata, therefore Sandbox refresh doesn't really work. What way we have to copy ALL the production metadata to other instances?


In my company we have Developpers pushing to QA sandbox and then to Preproduction and then production environnement.

One big issue we have, when the "sprint" is finished, and all the "sprint" content is on the production organization, we start refreshing all sandboxes.

Developpers like me are bored because each time we have a refresh, we loose our tests records etc...

At this time, the only way I found to keep some data is to create a "custom anonymous code" that create multiple record. In one execution I have some records with datas. It's the fast way I found. (As a developer, I update my script each time I add some fields, object etc...). This is the fastest way I found ! In one copy/paste on the developer console and...voila :)

The other way is to load data via Data Loader (extract and import). Extract from your QA environnement and load it to other sandboxes.

Good luck :)

  • Did you try solutions like Flosum? Using the Force Migration tool? – Edmondo1984 Nov 2 '17 at 9:15
  • No, we are building our proper continuous integration tool :D I'm using Ant migration tools who runs some schedulable scripts etc... #backtobasics :p – FabienHuot Nov 2 '17 at 9:50

The new way to do this is to use Salesforce DX. You can quickly spin up an org using a shell script that would look something like this:

sfdx force:org:create -f definitions/enterprise.json -s -a $1
sfdx force:src:push
sfdx force:data:tree:import -p data/data-plan.json

Which you would then call from your terminal:

./sfdx-create-org some-org-alias

You'll want to read the documentation for full details, of course, but the idea is that you can quickly spin up orgs for development, QA, and UAT.

If you want to use DX with Sandboxes, you can still take advantage of force:data:tree:import to quickly regenerate your data after you refresh by using something like the following:

sfdx force:org:web:login -r https://test.salesforce.com/ -s
sfdx force:data:tree:import -p data/data-plan.json

You can, of course, make them more or less complicated as you desire, but this should help you with your problem.

  • This is true up to a certain point, creating a scratch org which replicates from production requires almost half an hour for us. We have several managed and unmanaged packages installed – Edmondo1984 Nov 2 '17 at 16:56
  • @Edmondo1984 There's a lot of factors involved. I've found that even if fully spinning up a scratch org takes 30 minutes, even a dev sandbox can easily take an hour or longer to be available, which is one reason why I end up refreshing only when synchronizing becomes unbearable; it often takes me several hours to get back up and running when I refresh my dev sandbox, and DX significantly reduces that time. – sfdcfox Nov 2 '17 at 17:12
  • by the way, how this would keep the metadata synced between the three instances? – Edmondo1984 Nov 2 '17 at 17:16
  • @Edmondo1984 That's what force:src:push and/or force:mdapi:deploy is for. You can deploy any branch to any org using a simple command. DX makes it a lot easier to get your orgs up to date without ant scripts or other complicated mechanisms. If you haven't tried it yet, it's at least worth going through the trailhead for it and see if it can help you. – sfdcfox Nov 2 '17 at 18:13
  • 1
    @Edmondo1984 I've used mdapi to deploy seven managed package at once in a single deploy. It's not really as bad as it seems. I have a simple package.xml (<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Package xmlns="http://soap.sforce.com/2006/04/metadata"><types><members>*</members><name>InstalledPackage</name></types><version>36.0</version></Package>), with an installedPackages folder that contains all the packages I want to install. The docs say this isn't allowed, but it seems to work fine for now. – sfdcfox Nov 2 '17 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.