No — job variables templates do not support arbitrary function calls like

uuid4()

/

genuuid

. So this won’t work:

"my_uuid": "{{ genuuid }}"

And neither would something like:

"my_uuid": "{{ uuid4() }}"

Prefect job variable templating is *not full Jinja execution*; it’s basically placeholder substitution for known values. What you can use includes things like: -

{{ ctx.flow_run.id }}

-

{{ $ENV_VAR }}

-

{{ prefect.variables.some_var }}

-

{{ prefect.blocks.secret.my-secret }}

If you just need a unique value, the easiest option is often:

"my_uuid": "{{ ctx.flow_run.id }}"

If you specifically need a UUIDv4-format value, generate it before passing job variables, e.g. in Python:

python
import uuid

my_job_vars = {
    "my_uuid": str(uuid.uuid4())
}

or via an environment variable:

"my_uuid": "{{ $MY_UUID }}"

where

MY_UUID

is set by your worker/runtime environment. If helpful, I can suggest the best pattern depending on where you’re trying to use this job variable (Docker worker, k8s worker, ECS, etc.).

ctx

is a template context object that Prefect injects when rendering certain worker job template fields. In practice, it gives you access to flow and flow-run metadata during template rendering, e.g.: -

{{ ctx.flow.name }}

-

{{ ctx.flow_run.id }}

-

{{ ctx.flow_run.name }}

It’s not something you define yourself in the template. Prefect builds it at runtime when preparing the job configuration for a flow run. Conceptually, it looks like:

python
{
  "ctx": {
    "flow": ...,
    "flow_run": ...
  }
}

So

ctx

is just the top-level key for that runtime metadata. A couple important notes: -

ctx

is available for template rendering of worker/job configuration fields - the most commonly useful value is

{{ ctx.flow_run.id }}

- if there is no flow run context available for a field/render step, those values may be empty/unset - this is still data substitution, not executable template logic Example:

json
{
  "name": "job-{{ ctx.flow_run.id }}"
}

That would produce something like:

json
{
  "name": "job-2f3f0d34-4c9e-4f1a-a8a8-7c1f0a7c2abc"
}

If you want, I can also tell you which job template fields support

ctx

versus fields that only support plain variables/env/block references.

No —

ctx.flow_run

does not include a

root_flow_run_id

. What it does include is the serialized flow run object, so you can use things like: -

{{ ctx.flow_run.id }}

-

{{ ctx.flow_run.name }}

-

{{ ctx.flow_run.parameters }}

-

{{ ctx.flow_run.parent_task_run_id }}

For subflows, the relevant linkage available there is: -

ctx.flow_run.parent_task_run_id

But Prefect does not inject a computed root flow run ID into the worker template context. So if your question is: - current flow run id? → yes:

{{ ctx.flow_run.id }}

- root/original ancestor flow run id? → no, not directly in

ctx

Important distinction: Prefect does have runtime concepts around root flow run information during flow execution, but that’s different from the worker/job template rendering context. If you need the root flow run id in infrastructure config, you’d likely need to: - pass it explicitly as a parameter/job variable, or - compute it inside the flow and propagate it yourself. If you want, I can help sketch a pattern for propagating the root flow run ID through subflows in Prefect 3.x.

Yeah — the core limitation is: the root flow’s own job template is rendered before the root flow starts running, so the root flow cannot generate a UUID “just in time” and have that same value available in its own infrastructure/job template. So if the requirement is: 1. UUID is available in the root flow job template 2. UUID is also available to all descendant subflows 3. UUID is auto-generated if not explicitly provided then the UUID must be created before the root flow run is submitted/launched, not inside the root flow. What Prefect supports / doesn’t support -

job_variables

are effectively input to infrastructure creation, not mutable runtime state - a flow can read its job variables at runtime, but it cannot update its own already-rendered job template - subflows do not automatically inherit parent

job_variables

- for deployment-based child runs, you can explicitly pass

job_variables

when calling

run_deployment(...)

So there is no built-in “generate once automatically in template context and cascade everywhere” feature. Best-supported pattern Generate the UUID at the submission boundary and pass it as: - a flow parameter, and/or - a job variable / env var Then for every child deployment, explicitly forward it. For example:

python
import uuid
from prefect import flow
from prefect.deployments import run_deployment

@flow
def child_flow(my_uuid: str):
    print(my_uuid)

@flow
def root_flow(my_uuid: str):
    print(f"root uuid={my_uuid}")

    run_deployment(
        name="child-flow/child-deployment",
        parameters={"my_uuid": my_uuid},
        job_variables={
            "env": {
                "MY_UUID": my_uuid
            }
        },
    )

Then when starting the root flow, do something like:

python
root_uuid = str(uuid.uuid4())

run_deployment(
    name="root-flow/root-deployment",
    parameters={"my_uuid": root_uuid},
    job_variables={
        "env": {
            "MY_UUID": root_uuid
        }
    },
)

That gives you: - root infrastructure template access via

{{ env / job vars usage depending on worker config }}

- root flow parameter access - explicit propagation to child deployments - same pattern recursively for subflows-of-subflows If you want it “automatic if omitted” Then the automation has to live in the thing that creates the root flow run. Examples: - your CI/CD script - your app that triggers the deployment - an orchestration wrapper flow/service - an automation/webhook handler Pseudo-pattern:

python
def submit_root(my_uuid: str | None = None):
    my_uuid = my_uuid or str(uuid.uuid4())

    return run_deployment(
        name="root-flow/root-deployment",
        parameters={"my_uuid": my_uuid},
        job_variables={"env": {"MY_UUID": my_uuid}},
    )

That is the cleanest way to satisfy the root-template requirement. What won’t work This won’t solve the root template problem:

python
@flow
def root_flow(my_uuid: str | None = None):
    if my_uuid is None:
        my_uuid = str(uuid.uuid4())

because by then the root job has already been created. Possible fallback if flow-run ID is acceptable If you mainly need a unique stable identifier for root + descendants, using the root flow run ID is often easier. But as we discussed: -

ctx.flow_run.id

gives the current run id - worker template context does not expose

root_flow_run_id

So this helps at runtime inside flows, but not for root job template rendering. Bottom line If the UUID must be usable in the root flow’s job template, it has to be generated before the root flow run is created. There isn’t a Prefect-native template function or inheritance mechanism that can do this automatically from inside the root flow itself. If you want, I can help you design one of these two concrete patterns: 1. submission wrapper pattern for

run_deployment

2. parameter + env propagation pattern for a tree of deployed subflows