Thanks for the details — I think I see what’s happening. Assuming you’re on Prefect 3.x: subflows are full-fledged flow runs too. If your automation is keyed off “Flow run failed” and filtered primarily by flow name, both the parent and the subflow will match. If the subflow’s failure event lands first, it can “consume” the automation (e.g., because of once-per-window/cooldown semantics), and the parent’s event (which has the production tag and work pool labels you actually care about) won’t trigger the alert. The safest fix is to make sure your automation excludes subflow runs and/or only targets deployed parent runs. You’ve got a few reliable options: Recommended filter approaches - Prefer parent-only runs - Filter on “parent run” only. Concretely: - If available in the UI: set Flow run “Run type” = Parent - Or use an advanced filter that requires the parent field to be empty: flow_run.parent_task_run_id is null (subflows set this; parents don’t) - Or require “has deployment” - Parent deployment runs have a deployment_id; subflows typically do not. Filter where flow_run.deployment_id is not null - Prefer deployment/work-pool–based scoping instead of just the flow name - Filter by deployment name (or ID) and/or work pool labels. Subflows won’t have these, so they won’t match - If you do want to keep name-based filters, explicitly exclude subflows - Add a tag to subflow runs (e.g., subflow) and exclude it in the automation How to tag subflow runs in code If you’re calling the same flow as both a parent (via a deployment) and as a subflow, tag the subflow invocation so you can exclude it:

@flow(name="my_flow")
def my_flow(...):
    ...

@flow(name="parent_flow")
def parent_flow(...):
    # Tag child/subflow runs so your automation can ignore them
    my_flow.with_options(tags=["subflow"])(...)

Then, in your automation, add a filter like “tags does not contain subflow”. Double-check automation trigger semantics - If you have a cooldown or a “trigger only once within X minutes” setting, an earlier child-run failure can satisfy the trigger and suppress a subsequent parent-run event. Tighten your filters (as above) so only the parent can satisfy the trigger, or remove the broad name-only filter that lets the subflow in. If you can share your automation configuration (filters, any cooldown/grouping settings, and whether you’re filtering by name/tags/work-pool), I can suggest the exact filter setup. Specifically useful: - The event type(s) you’re using - Any “for each”/cooldown settings - Which exact fields you’re filtering on (flow name, tags, deployment, work pool labels, etc.) If after tightening filters you still see the parent not triggering when both fail, that could indicate a bug — happy to help reproduce with a minimal example and escalate.

Got it — and thanks for clarifying you’re on Prefect 2.x (Cloud). Here are two reliable ways to ensure you only alert on failed flow runs that were created by a deployment (i.e., exclude subflows with no deployment): Option A: Event trigger + “Deployment” resource present 1) Create a new Automation 2) Trigger: “An event occurs” 3) Event type:

prefect.flow-run.Failed

4) Filters → Resources: Add a filter for “Deployment” and set it to “Any” (or pick specific deployments) - This matches only events that include a Deployment resource, which ad‑hoc/subflow runs won’t have Option B: Flow-run state trigger + Deployment filter 1) Create a new Automation 2) Trigger: “When a flow run enters a state” 3) State: Failed 4) Filters: Choose your Deployment(s) (this restricts to deployment-backed parent runs) If you prefer a more surgical exclusion of subflows: - Add an advanced/payload filter to require that the parent indicator is absent, e.g. “flow_run.parent_task_run_id is null” (subflows set this; parent runs do not) - Or require “flow_run.deployment_id is not null” Notes - If you currently rely only on flow name, a subflow failure can match first and satisfy any “once per window” cooldown. Tightening to “has Deployment” (or selecting your specific deployment) prevents that. - If you’d like, share a screenshot of your Automation config (trigger type, filters/resources, and any cooldown), and I’ll tailor the exact settings for your workspace. Also, longer term: if/when you move to Prefect 3.x, the same principle applies—filter to deployment-backed runs or explicitly exclude subflows.