Short answer: best-effort “earliest scheduled first,” but no strict global ordering guarantee. Details: - When a worker becomes available, it asks the work pool for eligible flow runs. Prefect favors runs with the earliest scheduled start time — so “late” runs that were scheduled earlier are generally picked first. - If multiple runs have the same scheduled time, the pick among them is effectively unspecified. With multiple workers polling concurrently and any applicable concurrency limits, observed execution order can interleave and won’t be strictly FIFO. - Prefect 3.x does not expose a per-run “priority” setting that would override this behavior. If you need stronger ordering guarantees: - Run a single worker (or set very low capacity) on a dedicated work pool for that deployment to effectively serialize execution. - Isolate deployments into separate work pools if cross-deployment interleaving is a concern. - Use concurrency limits/serialization patterns to constrain parallelism where needed. Docs for context: Work pools in Prefect 3. If you can share your setup (Cloud vs. OSS, number of workers, any concurrency controls), I can suggest a concrete way to enforce your desired ordering.