The task
Scenario. orders_fact failed a null check on order_id this morning. The raw alert says something broke; it does not say who owns the table or which dashboards break next. Whoever is on call needs that context now, not after twenty minutes of digging.
The ask
- The owners of orders_fact and its DQ rule failures (Data Quality Studio)
- The downstream dashboards it feeds
- A warning announcement on the table with the failure details
Hero prompt
The orders_fact table failed a null check on order_id this morning. Find its owners and downstream dashboards, then add a warning announcement with the failure details so the team can triage.
Step by step
-
Pull the failing asset's owners, tags, announcements, and its current DQ rule failures and incidents.
The <table> failed a <null> check on <column> this morning — show its owners, tags, announcements and its current DQ rule failures and incidents.
-
Trace its downstream consumers.
Trace the downstream dashboards and tables that depend on <table>, so I know what's at risk.
-
Post a warning announcement with the failure details.
Add a warning announcement to <table> with the failure details so the team can triage.
What you'll give it
Required context
- The failing asset and what failed (orders_fact, null check on order_id)
- Lineage populated, so downstream consumers are real
- Permission to post announcements
Optional context
- The check's run details or a link, to paste into the announcement
- The on-call channel, if you also want a ping and not just the on-asset notice
- Data Quality Studio (or another data quality connector) enabled on the failing asset, to pull its actual DQ rule failures, not just a posted status
What Atlan creates
Outputs
- The owners of orders_fact, its DQ rule failures from Data Quality Studio, and the downstream dashboards at risk
- A warning announcement on orders_fact carrying the failure details
- A triage-ready picture: what broke, who owns it, what it hits
Summary. The alert arrives wrapped in the context that makes it actionable. On-call sees blast radius and ownership in one place, on the asset itself, instead of reconstructing it under pressure.
Changed: one warning announcement on the failing table. Left untouched: the data, the check, and every downstream asset, which are surfaced but not edited.
Follow-up prompts
Keep going once the first answer lands.
Warn the dependents
Post a short heads-up announcement on each downstream dashboard that this table failed a check today.
Draft the update
Write a two-line status update for the on-call channel summarizing the failure and who is affected.
Find the pattern
Show the current quality rules and any open incidents on this table, so I can see if it's a repeat offender.
Tips & troubleshooting
Post the announcement on the failing asset itself. Everyone downstream sees it in context.
- Match the tool to the work. During an incident, run it in whatever AI tool is already open; the value is speed, and the announcement is a small, safe write.
- Automate or chain it. Chain it to your quality tool: on any check failure, fire this recipe so the announcement is posted before a human even looks.
- Ask what it changed. Add "confirm which asset you posted the announcement on." One line, so you know exactly where the notice landed.