A nightly pipeline loads collection updates from twelve independent regional branch archives into a central Lakehouse using a single ForEach activity that processes branches one at a time. The pipeline finishes correctly every night but now runs long enough to delay the morning reporting refresh. The branches have no dependency on each other. What change would most directly reduce the pipeline's total run time?

A ForEach activity's sequential setting forces iterations to run strictly one after another even when there's no logical dependency between them; since the twelve branch loads are explicitly independent, running the ForEach in parallel lets multiple branch copies execute concurrently, cutting the pipeline's wall-clock time roughly in proportion to how many iterations run at once, up to the batch-count limit and whatever concurrency the sink and source can sustain. Splitting into twelve separate deployment pipelines is a lifecycle-management move for promoting Fabric items through environments — it doesn't change how fast the activities inside any one pipeline execute at runtime. A sensitivity label is a governance and compliance classification; it has no effect on job scheduling priority within a capacity. Adding fixed Wait activities does the opposite of what's needed here — it deliberately slows execution down to spread out resource use, which would make an already-too-slow pipeline even slower, not faster. A caveat: running iterations in parallel increases the load placed on the sink and on the Fabric capacity at once, so the batch count should be tuned against what the destination and capacity can actually absorb without throttling. A concrete check: compare the pipeline's total duration and the maximum concurrent activity count in monitoring before and after switching the ForEach to parallel execution.