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 (that was created from Main or your other 'source of truth' 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:
Sync lower environments (including developer sandboxes
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 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 to these environments.
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 Dev1 sandbox, next the three dots icon (top right corner), then toggle on/off Enable back propagation:
Back propagation for any given sandbox is enabled when there's a green tick showing next to Enable back propagation setting.
Note: This option, when enabled, creates PRs back to your selected feature branch created originally from Main. The back propagation PR will need to be manually promoted to the selected feature branch (you can do it within the Pipelines UI), and then you'd need to manually deploy changes from that feature branch to the Sandbox org.
Important to note: Back propagation to developer sandboxes is decided on developer sandbox level. This allows you to configure different behaviors 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 as well as their 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 deploy back propagated changes directly from your feature branch (source of the comparison) to your Developer Sandbox (target org).
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.