In Azure Data Factory, how do you make each hourly tumbling window wait for the previous window?

## Why window dependencies exist A tumbling window trigger creates a run per time slice, and by default those runs are independent: with `maxConcurrency` above 1, several windows can be in flight at once, and a failed window does not stop the next one. That is fine for a load that overwrites its own partition. It is wrong for anything cumulative — a running balance, a snapshot chain, a target table whose merge assumes the prior window is present. ADF's answer is a dependency declared on the trigger, not on the pipeline's activities. ## Self-dependency A self-dependency makes each window wait for an earlier window of the *same* trigger. It is expressed as an entry in `dependsOn`: ```json "dependsOn": [ { "type": "SelfDependencyTumblingWindowTriggerReference", "size": "01:00:00", "offset": "-01:00:00" } ] ``` Two properties do the work. `offset` shifts the dependency backwards in time — a negative offset of exactly one window length points at the immediately preceding window. `size` says how much of that shifted timeline must be satisfied; for a one-to-one predecessor relationship it equals the window length. The direction trips people up: a *positive* offset points forward and is not what a "wait for the previous run" requirement wants. Pair a self-dependency with `maxConcurrency: 1`. Concurrency alone only limits how many windows are in flight; it does not make window N wait for N-1 to *succeed*, and it does not stop the chain when a window fails. The dependency is what supplies ordering and blocking. ## Cross-trigger dependency The same array can name another tumbling window trigger: ```json "dependsOn": [ { "type": "TumblingWindowTriggerDependencyReference", "referenceTrigger": { "referenceName": "HourlyLoad", "type": "TriggerReference" }, "size": "1.00:00:00", "offset": "00:00:00" } ] ``` Here a daily window waits for a full day's worth of the hourly trigger's windows, because `size` spans a day of the upstream timeline. This is how a fan-in is expressed in ADF: not with an activity-level sensor, but by declaring at the trigger level which upstream slices a downstream slice consumes. Because both sides are window-aware, a backfill of the hourly trigger naturally unblocks the daily windows behind it. ## What a waiting window looks like In Monitor, trigger runs for a tumbling window trigger are listed per window with their own status. A window whose dependency is not yet satisfied is shown as waiting on its dependency rather than as failed, and it consumes no pipeline run. When the upstream window finally succeeds — often after a manual rerun — the dependent windows become runnable and drain in order, bounded by `maxConcurrency`. This is why an overnight outage produces a queue, not a hole: the windows exist, they are waiting, and clearing the blocker clears the backlog. It is also why a dependency chain needs alerting. Silence from a dependency-blocked chain looks identical to "nothing to do", so a freshness check on the target table matters more than a failure alert on the pipeline. ## Rerunning a window Because each window is addressable, the repair path is to fix the cause and rerun the specific window from the trigger runs view. The rerun receives the same `windowStartTime` and `windowEndTime`, so an idempotent pipeline — one that deletes-and-reloads or merges its own slice rather than blindly appending — produces the same result as the original run would have. If the pipeline appends, a rerun duplicates, and no amount of trigger configuration will fix that; idempotency is a property of the pipeline body, not of the trigger. ## Backfill interaction A backfill (a `startTime` in the past) plus a self-dependency means the historical windows replay strictly in order, one at a time. That is safe but slow: three months of hourly windows is a long serial queue. When the load is actually partition-independent, drop the self-dependency, raise `maxConcurrency` deliberately, and let the source's capacity — not the trigger — be the reason you throttle. Cost and source pressure during a backfill are governed by `maxConcurrency`, and setting it high on a shared source is a classic self-inflicted incident. ## Pitfalls to name in an interview - Expecting `maxConcurrency: 1` alone to enforce ordering and blocking. - Getting the sign of `offset` wrong and creating a dependency on a future window. - Adding a self-dependency to a load that does not need it, then wondering why a two-hour outage takes a day to drain. - Assuming a dependent window is skipped when its upstream fails; it waits instead, indefinitely, until someone acts. - Trying to express these dependencies between *schedule* triggers, which have no window state and therefore no dependency support.