Short answer: there isn’t a single “depends_on” field in a deployment that enforces ordering, but you can achieve strict ordering in Prefect 3.x in two solid ways: 1) Chain deployments with Automations (recommended for decoupled pipelines) - Configure Deployment B to trigger on the Completed event from Deployment A. B will only start after A finishes. - This keeps deployments independent and scales well. - Docs: Chain deployments with events and Automations concepts Example (Python) defining deployments with a trigger:

from prefect import flow, serve
from prefect.events import DeploymentEventTrigger

@flow
def flow_a():
    ...

@flow
def flow_b():
    ...

if __name__ == "__main__":
    a = flow_a.to_deployment(name="flow-a-prod")
    b = flow_b.to_deployment(
        name="flow-b-prod",
        triggers=[
            DeploymentEventTrigger(
                expect={"prefect.flow-run.Completed"},
                match_related={"prefect.resource.name": "flow-a-prod"},
            )
        ],
    )
    serve(a, b)

2) Use an orchestration flow that calls deployments in order - From a parent flow, call

run_deployment(...)

for A, wait for it to finish, then call B, etc. -

run_deployment

blocks by default (it waits for the triggered run to reach a final state unless you provide a timeout). - Docs: Trigger ad-hoc deployment runs and API ref prefect.deployments.flow_runs Example:

from prefect import flow
from prefect.deployments import run_deployment

@flow
def pipeline():
    a = run_deployment("flow-a/production", timeout=None)  # waits for A to finish
    if not a.state.is_completed():
        raise RuntimeError("flow-a failed, stopping pipeline")
    b = run_deployment("flow-b/production", timeout=None)  # starts after A completes

Related notes: - If you need to ensure sequential runs of the same deployment (no overlap), set a deployment-level concurrency limit of 1 with ENQUEUE; this doesn’t enforce cross-deployment order, but it prevents overlapping runs of a single deployment. Docs: Deployment concurrency limiting -

as_subflow=True

is the default when

run_deployment

is called inside a flow; it links the downstream run as a subflow in the UI. Set

as_subflow=False

if you don’t want that linkage. Docs: same API ref above. Quick guidance on choosing: - Want decoupled, event-driven chaining (A → B → C) across independent deployments? Use Automations/triggers. - Want a single “master” pipeline with conditional logic and explicit waits? Use an orchestration flow with

run_deployment

. Would you like help wiring this up for your specific flows? A couple clarifiers will help me tailor the example: - Are these separate deployments (A, B, C) that should chain every time A completes, or a single scheduled “batch” that must always run A then B then C? - Do you prefer a decoupled, event-driven setup (Automations) or a single orchestration flow that drives everything?