º£½ÇÌìÑÄÉçÇø

Struggling with Salesforce orgs that are out of sync? You’re not alone — it’s a problem that troubles many Salesforce teams. In this post we’ll take a look at how to keep your orgs in sync: why it matters, the challenges, and the best solutions.

What is environment syncing?

Environment syncing is the process of getting the latest version of your codebase in all of your orgs and branches, by regularly aligning them with your source of truth.

There are two typical options you can choose as your source of truth for Salesforce development. For teams using org-to-org development, the production environment tends to be the source of truth. For teams using a source-driven workflow, the most common source of truth is the main branch of their repository.

Why Salesforce environments get out of sync

Your Salesforce environments constantly change as you build features, deploy them along your release pipeline, and finally release them to your production org. Over time, more and more metadata differences between your environments begin to appear. There are three common ways metadata gets out of sync across orgs:

1. Abandoned projects. The whole point of sandbox and developer orgs is that you can build and test customizations without worrying too much about the impact. But any changes you try out and then decide not to deploy can quickly clutter up your sandbox.
2. Long-term projects. Other projects aren’t abandoned, but are deliberately held back from releases until they’re completed or have reached certain milestones. Without careful management of long-term projects, the resulting drift between environments poses a huge challenge.
3. Teammates’ work. If you and your teammates all have your own developer orgs, the chances are they don’t look alike. At some point your changes are being integrated for release. But do you deploy your teammates’ work back to your org? If not, it’s hard to be sure what you’re building will play nicely with the apps and features others have been working on.
4. Hotfixes. At the other end of your release pipeline, any hotfixes made directly in production won’t appear in upstream environments without back promotion. This means there’s a risk your hotfix will be overwritten or deleted during a release later on.

Why does syncing up orgs matter?

Ideally, all environments should be in sync with your chosen source of truth, so you don’t hit issues with releases. Synced orgs lead to:

• More reliable testing. If you’re testing work in a sandbox that isn’t in sync with your source of truth, then you won’t discover every problem before releasing that work. There might be an edge case that causes your work to fail in production.
• Decluttered comparisons. If you’re using º£½ÇÌìÑÄÉçÇø’s comparison tool to see the metadata differences between your orgs, having orgs that are massively out of sync will throw up a huge number of differences, and you’ll need to search carefully for the changes you really care about.
• Easier deployments. The likelihood of deploying successfully between out-of-sync environments is lower because the metadata in your target environment may not be the right shape to receive the deployment package.
• Successful automation. Adding automation to your release pipeline using continuous integration jobs relies on environments that are in sync. CI jobs are designed to automate frequent deployments of incremental changes. The more metadata a CI job is trying to deploy, the more likely it is to fail.

It’s best practice to align your environments to the source of truth after every release. This ensures every org and branch contains all the new development that’s gone into your source of truth. There are a variety of ways to sync your sandboxes and other environments with your source of truth, and different options will suit different teams. Let’s look at some of the common ways that teams align their environments and how adopting Gearset Pipelines boils that process down into a click of a button.

Manual deployments

You can use tools such as change sets, DevOps Center and the Salesforce CLI to manually deploy changes across your environments and keep them in sync. It’s worth noting that these options don’t flag the metadata differences between your environments. So you’ll need to keep track of what changes have been made and where your environments have diverged, in order to build a deployment package that aligns your source and target environments.

DIY automation

If you’re already using version control, you can script and maintain a DIY automation pipeline using SFDX commands, Git, and a CI server. This approach allows you to align the changes in a particular branch with a specific sandbox environment. For example, aligning your main branch with production means the scripts will identify the changes in your main branch and automatically deploy them to production. This process can be applied to any branch and org, making this a very flexible approach to sandbox syncing.

If you’re implementing a DIY automation process for sandbox syncing, you’ll need to be reasonably technical as you’ll have to write your own scripts and execute them using a CI server. You’ll also need someone to maintain the scripts and CI operations, to make sure they’re running effectively and improving them over time.

Still developing something that’s not made it to production? To avoid overwriting in-progress work in your orgs, you’ll need to stash changes before the automated deployment is executed.

Salesforce’s sandbox refresh

in Salesforce is the traditional way to get it in sync with your production org. Running this process brings the sandbox’s metadata in line with production and, depending on your sandbox type, it may update the data as well. This can be an effective option, especially if your orgs are really out of sync.

Refreshing a sandbox does have some drawbacks to be aware of:

• There’s no visibility into what you’re overwriting in the sandbox, so you might accidentally lose development work that hasn’t yet made it to production.
• Salesforce can take several days to complete the refresh, during which time you won’t have access to your sandbox.
• Salesforce limits you can refresh your sandbox.
• The refresh isn’t strictly a migration to your existing sandbox; it tears down the old sandbox and replaces it, which means your sandbox will sometimes ‘’ to a different Salesforce instance.
• There are quirks in Salesforce that mean your refreshed sandbox of production.
• This process is only available for sandbox orgs, not developer orgs.

If you’re a small team with a slow release cadence and a simple release pipeline of a few orgs, then Salesforce’s sandbox refresh might work for you, but most teams need more powerful tools.

Easy org syncing with º£½ÇÌìÑÄÉçÇø

Sandbox management can feel like a headache but the good news is that it doesn’t need to. There are two key ways that teams can easily keep their orgs in sync with º£½ÇÌìÑÄÉçÇø — either through compare and deploy, to identify differences and align the environments, or automatically with Pipelines. Let’s look at how º£½ÇÌìÑÄÉçÇø can take the pain out of sandbox syncing and make Salesforce environment management easy.

If you want to follow along, .

Get your orgs in sync using º£½ÇÌìÑÄÉçÇø compare and deploy

º£½ÇÌìÑÄÉçÇø can immediately bring visibility, control and speed to your sandbox refresh process, even if you haven’t yet adopted DevOps. Here’s how:

1. Compare your orgs

Run a comparison in º£½ÇÌìÑÄÉçÇø with your source of truth as your source and the environment you’re looking to sync as the target. Make sure you select Compare all in the metadata filter.

2. Analyze the differences

As this kind of comparison is the reverse of a typical comparison, so it will back propagate changes instead of promoting them forwards along your pipeline.

When production or your main branch is the source of the comparison, the New items tab shows you any metadata that isn’t in the sandbox or lower environment, i.e. any changes that have been made directly in production as a hotfix or bypassing the official deployment process. The Deleted items tab shows you metadata in the sandbox that isn’t in production, which could be in-progress or abandoned work. And the Changed items tab shows you the metadata items that are in both environments but have been modified or differ in some way.

If your team has been following the right development process, the source of truth should have the ‘correct’ version of this metadata, but be sure to check that there isn’t any development work in the lower environment that hasn’t been deployed yet. º£½ÇÌìÑÄÉçÇø’s filters in the Changed on column will help you identify the most recent work.

3. Decide whether to refresh

If your orgs are badly out of sync Salesforce’s sandbox refresh is probably your quickest option. Remember to rescue any changes in your sandbox first if you spotted anything in the comparison view that you want to keep. After you’ve refreshed the sandbox, run another comparison in Gearset. A refreshed sandbox isn’t always totally in sync with production, and º£½ÇÌìÑÄÉçÇø can help you get them closer.

4. Deploy metadata

If your environment config hasn’t drifted too far apart, you can select all the changes in the comparison view (assuming you’ve not identified anything in the sandbox you should keep) and deploy them using Gearset.

You might want to run this as a if there are many changes.

Keep your orgs in sync using Gearset Pipelines

Getting your Salesforce sandboxes in sync is one thing; keeping them in sync is another. Especially when there are multiple sandboxes in play.

Version control, which underpins the DevOps process, is designed to keep everything in sync. But even when using version control, dev environments can get out of sync from the main branch and each other if changes aren’t deployed back to these upstream environments. It’s all too easy to skip this step when you’re working in Salesforce orgs, because it calls for yet another deployment in your workflow.

Here’s where setting up CI/CD using º£½ÇÌìÑÄÉçÇø’s Pipelines is a game changer. º£½ÇÌìÑÄÉçÇø tracks any promotions to the main branch and will list them as updates that can be back promoted to your developer sandbox in one click.

There’s no pull request, branch, or merge that needs to be worked through — instead, º£½ÇÌìÑÄÉçÇø will highlight all the changes to your source of truth and the order in which they were shipped. You can then deploy them back to your sandbox in one go or chronologically if there are dependencies between updates.

After clicking Update now, º£½ÇÌìÑÄÉçÇø will automatically detect whether this sync impacts any in-progress development in your sandbox and capture the changes. Where possible, º£½ÇÌìÑÄÉçÇø will intelligently resolve these issues with semantic merge. Anything that can’t be resolved automatically will be flagged as a merge conflict for manual resolution.

Gearset Pipelines removes the time consuming overhead of keeping your orgs in sync. Luxury hospitality organization, The Leading Hotels of the World, used to spend precious time syncing up their Salesforce orgs every 6 months — but no longer. The solution for them and so many other businesses? Gearset Pipelines.

Sandbox seeding

Even when the metadata is synced between your environments, don’t forget about the data too! If data is constantly being added to production by your end users the datasets in your testing environments quickly get out of date.

Use º£½ÇÌìÑÄÉçÇø’s data deployments to easily seed your sandbox org with reliable data for testing and protect sensitive data and PII with data masking.

Say goodbye to that syncing feeling

If you’re new to º£½ÇÌìÑÄÉçÇø, get in touch with us to book a tailored demo and find out how º£½ÇÌìÑÄÉçÇø can help you keep your environments in sync. Want to see it in action? Watch how easy it is to sync environments with Gearset Pipelines.