Short answer: usually no — not as the primary design goal. With

DeploymentEventTrigger

, events can carry data that gets mapped into flow parameters, but the better pattern is: - use the event to identify what happened - include just enough context to route/filter/lookup - let the flow fetch the authoritative data from the source system So instead of treating the event like a full flow invocation payload, treat it like a trigger + reference + minimal context. What events should usually contain - A clear event name, like

order.completed

- A stable resource identifier in

resource

- Labels/metadata useful for matching/filtering - Optional payload fields if the flow genuinely needs them immediately Good example

text
event = "order.completed"
resource.prefect.resource.id = "order.12345"
payload = {
  "customer_id": "cust-9",
  "source": "shopify"
}

Then your triggered flow can: - receive

order_id

/

customer_id

- query Shopify / your DB for the full order details Why this is preferred - event payloads are often partial or stale - schemas evolve - source systems remain the system of record - flows become more robust and replayable When it is OK to pass parameters in the event If the triggered flow truly operates on the event payload itself, or the payload is the only source of truth, then yes — include the needed fields and template them into deployment parameters. For example,

DeploymentEventTrigger

parameters can be templated from the event:

python
from prefect.events import DeploymentEventTrigger

trigger = DeploymentEventTrigger(
    expect={"order.completed"},
    parameters={
        "order_id": {
            "__prefect_kind": "jinja",
            "template": "{{ event.resource.id }}"
        },
        "customer_id": {
            "__prefect_kind": "jinja",
            "template": "{{ event.payload.customer_id }}"
        }
    }
)

But I’d still recommend only passing: - IDs - small routing fields - lightweight context not huge business objects unless there’s a strong reason. Rule of thumb - Put identifiers in the event - Put filtering dimensions in labels/resource metadata - Put small optional context in payload - Fetch full execution data inside the flow If you want, I can also show: 1. a recommended event schema for

DeploymentEventTrigger

, or 2. a full Prefect 3 example of event emission + trigger + flow parameter templating.