A pipeline uses a ForEach activity to run a copy-and-notebook sequence once per branch across all twelve museum branches. Once every branch has finished, a final notebook needs to run a single aggregation across all twelve branches' results together. Right now the aggregation notebook sometimes starts before every branch iteration inside the ForEach has finished. What is the underlying orchestration mistake?

A ForEach activity in a pipeline completes only once all of its iterations have finished, and a downstream activity that depends on the ForEach activity's own success or completion will correctly wait for that full fan-in before starting. If the aggregation notebook is starting early, the real issue is that it isn't wired with a proper dependency on the ForEach activity itself, so the pipeline's control flow doesn't actually treat it as coming after the loop finishes. Running the ForEach sequentially versus in parallel affects how fast the twelve branches process relative to each other, but it doesn't change whether the aggregation step waits for the loop to finish — that's a dependency question, not a concurrency setting. Concluding the branches should never have used a ForEach activity throws out a pattern that's exactly right for looping the same logic over a list of items; the fan-out itself isn't the problem. A missing retry count on the inner Copy activity could cause a given branch's iteration to fail on a transient error, but that's unrelated to why the downstream aggregation step is starting too early — it's a resiliency gap, not a sequencing one. The caveat: even with the dependency wired correctly, an individual iteration that fails outright can still affect whether the ForEach is considered fully succeeded, so failure handling inside the loop matters too. A concrete check: examine the pipeline's activity graph and confirm the aggregation notebook has an explicit dependency arrow drawn from the ForEach activity, not from some other upstream step.