This article explains how to get your features back-propagated through your Gearset Pipeline into the lower (static) environments.

By lower environments we mean specifically your long-lived Git branches, which are the source environments of your CI jobs - in the context of Gearset Pipelines.

Salesforce environments constantly change as you build features, deploy them, and release them to your production org.

Sometimes a hotfix is what you need to release quickly, and skipping parts of the release pipeline is needed. Over time, more and more metadata differences between your environments begin to appear.

Being able to back propagate (or back promote) features eases the task of aligning changes across all environments. And, most importantly, it allows developers to work from the most relevant code.

Ultimately, it leads to encouraging more frequent releases and reduces the likelihood of experiencing environment drift and overwriting work.

In promoting your first features article we guide you on how to forward propagate your changes with our Pipelines solution.

Let’s now look at how you can get your orgs synced and automatically make merged changes available for promotion to lower environments in the Pipeline.

The logic is simple: Gearset allows you to forward and back propagate, automatically creating (but not promoting) PRs on your behalf.

The way you can do this depends on what you’re trying to achieve. Before you go ahead, consider the steps we describe below.

If your team does hotfixes and needs to get them back propagated to other (lower) Pipeline environments, but doesn't necessarily need to refresh metadata in Dev Sandboxes, then a setup similar to Pipeline shown on image below is required.

The tool automatically back propagates changes if they were to be merged straight into higher environments.

Example: A new PR opened from Hotfix environment, and promoted through the Pipeline by merging it into Main, would automatically create back propagation PRs into lower static environments (highlighted in green) - in this case UAT and INT.
​

If a PR is merged directly into Main branch (i.e. outside the Pipeline), it would also back propagate this change into UAT and INT (again only the static environments highlighted in green).

The recommended back propagation set up is to configure the Gearset Pipeline to create back propagation pull requests Only when changes are promoted into the final environment.

Click the cog icon: on the Pipelines UI page to find this setting.

A short video to show this option in Edit pipeline settings:

Gearset allows you to enable updates directly to your Dev Sandboxes. This way you can back propagate (or back promote) changes directly to your Pipeline's Sandboxes.

You can decide which Sandbox in the pipeline to enable updates for. To do it, simply click on a given Sandbox and then select the three dots icon:- you'll then see a dropdown menu with Enable updates option.

A short video to demonstrate the setting:
​

Configuring your Pipeline this way means that if you promote changes from one Dev Sandbox into to next environment in the Pipeline (e.g. INT), or in fact into any further static environment in the Pipeline (e.g. UAT), you are not yet triggering back propagation of the changes to any lower static environment.

This is simply because the changes begin to be back propagated to lower static environments only after being merged in Main/Master branch (and released in Production).

This is because a best practice and our recommendation is that you aim to have these changes tested and merged into Prod before they're being back propagated.

This options means that if you promote changes from any Developer Sandbox into the next environment in the Pipeline (e.g. INT), the back propagation to other Sandboxes in the Pipeline will be initiated.

At the same time, after the PR is successfully merged into the INT, it also forward propagates to UAT.
​
Back propagation will only happen to those Sandboxes that have the Enable updates option activated.

Remember that back propagation happens only to the static environments or Dev Sandboxes that don't yet contain the promoted changes.

The main benefit of working this way is that changes sync up a lot quicker in lower environments. However, this can create more noise within your Pipeline.

This way of syncing may allow developers working on new changes in their respective Sandboxes to get access to the latest features and user stories promoted through the Pipeline before these features/stories reach the Production.