A conservation team wants a curator-maintained Dataflow Gen2 to do light cleanup on daily humidity-sensor exports, followed by a PySpark notebook that performs heavier statistical aggregation before the results land in the Lakehouse. They want both steps to run as one dependable, monitorable nightly flow rather than two separately scheduled items. How should this be orchestrated?

Placing both steps as activities inside a single pipeline, with the Notebook activity's dependency condition set to run on the success of the Dataflow Gen2 activity, gives a true cause-and-effect chain: the aggregation never starts against incomplete or stale cleaned data, and the whole flow shows up as one run in the Monitoring hub. Staggering two independently scheduled items relies on the Dataflow Gen2 always finishing inside its allotted window, which breaks the moment sensor volume spikes or the low-code refresh runs slow, and there is no dependency to catch that. Merging everything into one notebook throws away the curator-maintained, low-code cleanup step the conservation team specifically wanted kept accessible without Spark skills, and burdens the notebook with logic it was never meant to own. Manually running each step reintroduces human timing risk into what should be a hands-off nightly process, and it defeats the ask for a single dependable flow. The caveat: this pattern only helps if the dependency condition is set correctly — a completed condition would let the notebook run even after a Dataflow Gen2 failure. A concrete check: intentionally fail the Dataflow Gen2 in a test run and confirm the notebook activity is skipped rather than executing anyway.