Great question — can you share where you’re using the Jinja template in Prefect (e.g., flow run names, work pool job variables/env, automations like RunDeployment, or deployment fields)? The available context varies a bit by place. At a high level in Prefect 3.x, Jinja templates generally give you these objects: - flow_run — id, name, flow_name, flow_version, parameters, tags, scheduled_start_time, parent_flow_run_id, root_flow_run_id, run_count, api_url, ui_url, job_variables - parameters — convenience access to the same dict as flow_run.parameters - deployment — info about the deployment (name/id/version) where applicable - flow — info about the flow (name/id/version) where applicable - work_pool / work_queue — available in places like job templates/automations - task_run — available where task-level templating is used (e.g., task run names) - variables — Prefect Variables (org/workspace-level key-values) - env — process environment variables (when enabled in a given context) Common examples - Flow run name:

{{ flow_run.flow_name }}-{{ parameters.customer|lower }}-r{{ flow_run.run_count }}

- Work pool job environment (e.g., Process, Docker, K8s):

{
  "ENV": "prod",
  "RUN_ID": "{{ flow_run.id }}",
  "CUSTOMER": "{{ parameters.customer|lower }}"
}

- Automation → RunDeployment parameters (Jinja mode):

{
  "param_from_upstream": {
    "__prefect_kind": "jinja",
    "template": "{{ flow_run.parameters['value'] }}"
  }
}

Notes and caveats - Jinja expressions typically render to strings. If your target parameter expects an int/float/bool, you may need to cast or pass a literal. There’s an open issue about numbers being coerced to strings in automations: Issue #18907. - Standard Jinja filters (e.g., lower, upper, replace) are available; prefer simple expressions that resolve cleanly to strings (especially in job templates and automations). - Missing keys will error in some contexts; make sure the field exists (e.g., a parameter is provided on run). If you tell me the exact spot you’re templating (e.g., “flow run name on deployment”, “job env in a Docker work pool”, or “RunDeployment automation parameters”), I can give you the precise context keys and a working example for that screen.

Got it — if you’re using Jinja in Prefect 3.x, here’s what you can and can’t pull in: What you can access reliably in Jinja - flow_run metadata: id, name, flow_name, flow_version, parameters, tags, scheduled_start_time, parent/root ids, run_count, api_url, ui_url - Examples: -

{{ flow_run.id }}

,

{{ flow_run.name }}

-

{{ flow_run.parameters['customer_id'] }}

or

{{ parameters.customer_id }}

- deployment/flow/work_pool/work_queue info: available in places like RunDeployment automations and job templates - variables:

{{ variables.MY_VAR }}

(read-only in templates) - env vars:

{{ env.MY_ENV_VAR }}

(in contexts that expose env) What you cannot access directly in Jinja - The actual return value of a flow (e.g., Python object returned by your @flow) - It’s not included in the Jinja context and may be stored in result storage; fetching it requires code/client access, not templating. - Artifacts created by a run unless your template is evaluated in response to an artifact event (see below). How to get “returned values” and artifacts into Jinja-driven workflows Option A: Use an artifact-triggered automation - Emit an artifact in your upstream flow with a known key pattern, then trigger an automation on artifact creation. In that automation, Jinja gets an artifact object. - Flow:

from prefect import flow, runtime
from prefect.artifacts import create_markdown_artifact
import json

@flow
def upstream():
    result = {"total": 42, "status": "ok"}
    create_markdown_artifact(
        key=f"run-output-{runtime.flow_run.id()}",
        markdown=json.dumps(result),
        description="Serialized flow result"
    )
    return result

- Automation (trigger: “artifact created” where key startswith “run-output-”) → RunDeployment parameters:

{
  "raw_json": {
    "__prefect_kind": "jinja",
    "template": "{{ artifact.data }}"
  },
  "artifact_key": {
    "__prefect_kind": "jinja",
    "template": "{{ artifact.key }}"
  }
}

- Note:

artifact.data

for markdown artifacts is a string. Parse JSON in the downstream flow. Option B: Pass data via parameters (if you control the trigger) - If you’re launching the downstream flow from Python (subflow or a client call), pass the values as parameters directly instead of relying on Jinja. Option C: Persist and reference a location - Persist your output somewhere (S3/GCS/local path/DB) and pass the reference in Jinja (e.g., a URI or key). The downstream flow loads it in code. Important caveats - Jinja usually renders to strings. If the downstream parameter expects a number/bool, cast in your downstream code or accept a string. There’s an open issue where templated parameters become strings in automations: prefect#18907. - If you are using a flow-run-completed trigger (not artifact-created), the Jinja context includes

flow_run

but not the flow’s return value or artifacts. Use Option A if you need artifacts/data at template time. If you can share exactly where you’re templating (e.g., “RunDeployment action in an automation after upstream completes” vs “job env for a worker” vs “flow run name”), I’ll give you the precise Jinja variables available there and a tailored example.