Prefect Data Orchestration Cheat Sheet

Updated 2026-05-15

🧠Study flashcards on this topic99 cards · spaced repetition→

Prefect is a modern Python workflow orchestration framework designed to turn any Python function into a reliable, observable data pipeline. Unlike legacy orchestrators that require complex YAML DAG specifications, Prefect uses native Python decorators (@flow, @task) to add orchestration capabilities while keeping code testable and intuitive. The framework embraces dynamic, event-driven workflows where tasks map over runtime data, flows pause for human approval, and automations trigger on custom events — all without forcing your logic into rigid graph structures. Prefect's hybrid execution model (client-side task orchestration with server-side tracking) means flows run anywhere — a laptop, Docker container, Kubernetes pod, or cloud function — with full observability into every state transition, retry, and cache hit.

What This Cheat Sheet Covers

This topic spans 16 focused tables and 110 indexed concepts, 99 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Decorators and Flow DefinitionTable 2: Retry and Cache ConfigurationTable 3: Deployments and Execution InfrastructureTable 4: Scheduling PatternsTable 5: Automations and Event-Driven TriggersTable 6: State Handlers and Lifecycle HooksTable 7: Artifacts and Result DisplayTable 8: Concurrency and ParallelismTable 9: Logging and ObservabilityTable 10: Prefect Cloud Workspace and RBACTable 11: Prefect Server Self-Hosted DeploymentTable 12: Advanced Flow and Task PatternsTable 13: Deployment and Production PatternsTable 14: Comparing Prefect to Other OrchestratorsTable 15: CLI Commands and Developer WorkflowTable 16: Prefect 3.0 Features (as of 2026)

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Decorators and Flow Definition

Everything in Prefect starts with two decorators — @flow wraps a function as an orchestrated workflow and @task marks the discrete units of work inside it. Master these and you understand the whole mental model: parameters are typed and validated at runtime, subflows compose pipelines from smaller flows, and async variants unlock concurrent execution for I/O-bound work.

Decorator	Example	Description
@flow	`@flow(name="etl_pipeline")` `def etl(): ...`	• Wraps a Python function as an orchestrated workflow • creates a flow run when called with full state tracking and observability
@task	`@task(retries=3)` `def extract(): ...`	• Wraps a function as a discrete unit of work within a flow • task runs are client-side, can be retried and cached individually
flow parameters	`@flow` `def my_flow(param: int): ...`	• Defines typed inputs to a flow • validated at runtime, visible in the UI, and can be overridden per deployment
task parameters	`@task` `def process(data: list): ...`	• Standard function arguments passed to tasks • serialized for caching and logging, used in cache key computation
@flow with serve()	`if __name__ == "__main__":` `my_flow.serve(name="prod")`	• Serve a flow as a long-running deployment with an in-process scheduler • no separate worker process needed for simple use cases
nested flows (subflows)	`@flow` `def parent():` `child_flow()`	• Calls another flow from within a flow • subflow runs are tracked independently with full state inheritance
async flows	`@flow` `async def my_async_flow(): ...`	• Defines an asynchronous flow • allows use of `await` and async task execution for I/O-bound workflows
async tasks	`@task` `async def fetch_data(): ...`	• Asynchronous task • can be awaited within async flows or executed concurrently with async task runners

Table 2: Retry and Cache Configuration

The reliability and efficiency knobs you pass into @task. The retry family — attempts, delays, and jitter — handles flaky APIs and transient failures gracefully, while the cache and result family skips redundant work by reusing prior outputs and controls how, where, and for how long those results are stored. Together they turn an ordinary function into one that's both resilient and fast on repeat runs.

Parameter	Example	Description
retries	`@task(retries=3)`	• Number of automatic retry attempts on task failure • applies to transient errors or flaky external dependencies

The rest of this section is part of the full cheat sheet

Table 3: Deployments and Execution Infrastructure

This is how a flow goes from your laptop to running on a schedule somewhere in production. A deployment packages the flow with its config; work pools and workers form the pub/sub system where deployments submit runs and workers pick them up; and infrastructure blocks plus the various serve/deploy paths decide whether runs land in Docker containers, Kubernetes Jobs, or a simple in-process scheduler.

Concept	Example	Description
deployment	`prefect deploy`	Packaging a flow with schedule, triggers, infrastructure config, and metadata to enable remote execution via the Prefect API.

The rest of this section is part of the full cheat sheet

Table 4: Scheduling Patterns

The three ways to express when a deployment should run: cron for familiar Unix expressions, intervals for simple fixed gaps, and RRule for genuinely complex recurrence like "first Monday of every month." Timezone-aware scheduling handles DST automatically, and a single deployment can carry multiple schedules or pause them without losing the definition.

Schedule Type	Example	Description
CronSchedule	`from prefect.client.schemas` `import CronSchedule` `CronSchedule(cron="0 9 * * *")`	• Unix cron expression • supports standard 5-field syntax plus optional seconds field, timezone-aware execution

The rest of this section is part of the full cheat sheet

Table 1: Core Decorators and Flow Definition

Decorator	Example	Description
@flow	`@flow(name="etl_pipeline")` `def etl(): ...`	• Wraps a Python function as an orchestrated workflow • creates a flow run when called with full state tracking and observability
@task	`@task(retries=3)` `def extract(): ...`	• Wraps a function as a discrete unit of work within a flow • task runs are client-side, can be retried and cached individually
flow parameters	`@flow` `def my_flow(param: int): ...`	• Defines typed inputs to a flow • validated at runtime, visible in the UI, and can be overridden per deployment
task parameters	`@task` `def process(data: list): ...`	• Standard function arguments passed to tasks • serialized for caching and logging, used in cache key computation
@flow with serve()	`if __name__ == "__main__":` `my_flow.serve(name="prod")`	• Serve a flow as a long-running deployment with an in-process scheduler • no separate worker process needed for simple use cases
nested flows (subflows)	`@flow` `def parent():` `child_flow()`	• Calls another flow from within a flow • subflow runs are tracked independently with full state inheritance
async flows	`@flow` `async def my_async_flow(): ...`	• Defines an asynchronous flow • allows use of `await` and async task execution for I/O-bound workflows
async tasks	`@task` `async def fetch_data(): ...`	• Asynchronous task • can be awaited within async flows or executed concurrently with async task runners

Table 2: Retry and Cache Configuration

Parameter	Example	Description
retries	`@task(retries=3)`	• Number of automatic retry attempts on task failure • applies to transient errors or flaky external dependencies

Table 3: Deployments and Execution Infrastructure

Concept	Example	Description
deployment	`prefect deploy`	Packaging a flow with schedule, triggers, infrastructure config, and metadata to enable remote execution via the Prefect API.

Table 4: Scheduling Patterns

Schedule Type	Example	Description
CronSchedule	`from prefect.client.schemas` `import CronSchedule` `CronSchedule(cron="0 9 * * *")`	• Unix cron expression • supports standard 5-field syntax plus optional seconds field, timezone-aware execution