When you setup your Pipeline (full guide here), you'll have:
Developer sandboxes: the boxes on the left with listed blue represent your developer sandboxes and associated short-lived feature branches, and have no corresponding CI jobs because features branches change often and it's dynamic. These environments intend to allow you to create feature branches, commit into it from your developer sandboxes and open PRs into the pipeline.
Static environments: the boxes on the right in green represent your CI jobs, and they are static because its source long-lived environment branch and target org aren't changing for each feature. These environments intend to automate deployments or validations from version control into your orgs.
More info on the branching model user here if needed.
When it comes to static environments (CI jobs), back-propagation happens automatically. Learn more about that process here. Referring to said dynamic developer sandboxes, you can 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. This is decided on developer sandbox level, so you can decide different behaviours for different developer sandboxes. You could decide to keep the toggle off for some developer sandboxes and toggle on for others where you're comfortable with how it works.
Why would I disable this option?
Because the different environment types have different functions in your pipeline, you'll interact with them differently and 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.
Why do we have the option to toggle on 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 fit, it's possible to use this option. If that's the case:
Toggle on (enable) the option
After merging the 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.