This option does not automatically push changes from the pipeline to the org. PRs that are synced this way will only be added to the currently selected feature branch.
We do not recommend using this option to back propagate to Dev Sandboxes.
To correctly enable back propagation in your developer sandboxes follow the steps given here.
When you setup your Pipeline (full guide in: Setting up your first Gearset Pipeline), you'll come across with:
Developer sandboxes: the boxes on the left (in blue) represent your developer sandboxes and associated short-lived feature branches. These environments have no corresponding CI jobs because features branches (to which you'd be committing from Dev sandboxes) change often, which makes these environments dynamic.
From developer environments you can create feature branches, commit into existing feature branches and open PRs (pull requests) into other (static) environments located downstream in your Pipeline workflow.Static environments: the boxes on the right (in green) represent your CI jobs. They are static because their long-lived (Git) branches and target orgs don't change as you promote new features through the Pipeline. These environments allow you to automate deployments (or run validations) from your version control system (i.e. GitHub, Azure DevOps etc) into their target orgs.
You can find more information on the branching model in this article:
Below photo shows an example of how a developer (blue) and static environment (green) would look within the Pipeline:
When it comes to the static environments (CI jobs), back propagation happens automatically. Learn more about that process from our article about Org syncing with Pipelines.
How to disable back propagation in developer sandboxes
Referring back to dynamic developer sandboxes, you can choose to enable or disable back propagation into them.
To do so, you just need to click on each developer sandbox within your Pipeline and toggle it on or off.
On below example, I clicked on Dev2 sandbox, then the three dot icon (top right corner), then select Enable back propagation:
Back propagation for any given sandbox is enabled when there's a tick mark showing next to it (no tick mark = back propagation is disabled):
Important to note: Back propagation to developer sandboxes is decided on developer sandbox level. This allows you to configure different behaviours for different developer sandboxes within your Pipeline.
For example, you can decide to keep the back propagation disabled for some developer sandboxes while having it enabled for others as you test the feature while getting comfortable with how it works.
Why would I disable this option?
Because different environment types have different functions in your pipeline, you'll interact with them differently. This means that back-propagation will also behave differently depending on which type of environment it is targeting. And enabling it for developer sandboxes brings its own limitations:
It's less automatic: Because they aren't CI jobs, they won't kick off an automatic deployment to developer orgs. Even if a feature back propagates reaching this dynamic box and PR is open against the feature branch, the automation stops there and still requires manual work to update the sandboxes.
It pollutes feature branches: One of the benefits of pipelines is to isolate features so you can move each feature at their needed pace without having an untested feature stopping the promotion of other tested and approved features.
If you were to back-propagate into an unrelated feature branch, the changes are no longer isolated and you get your feature branch polluted with mixed changes. To keep it separate and clean, we recommend the methods mentioned above (back propagation only to static environments).
Why do we have the option to enable back propagation to Dev Sandboxes if it's not recommended?
We want to advise you on best practices and pros and cons. Depending on how your team works, and if you see it fit, it's possible to use back propagation to Dev Sandboxes. If that's the case:
Enable this option
After merging a PR into the feature branch you'd need to do a manual 'Compare and deploy' and reverse the order for the developer sandbox to be the target to then run a manual compare and deploy.
If you wish to keep your developer sandboxes in sync whilst understanding that keeping this off is the best for your team, you can learn how in our Org syncing with Pipelines article.