Domo dashboard card error "dataflow failed" after schema change troubleshooting

TL;DR

Fix the dataflow, not the card. Open the dataflow, find the transform that references the changed column, update it to the new schema, save and run the dataflow to completion, and the card recovers on the new output. Domo cards read the dataflow output dataset, so an upstream schema change that breaks a transform leaves every downstream card erroring or stale at once.

dataflow failed

Use this when

• Cards on one output dataset error after the input dataset schema changed.
• The dataflow run history shows a failed run at the time the cards broke.
• The source system or connector changed column names or types recently.

Not for this skill when

• The dataflow runs successfully but the card shows wrong values. Review the card and transform logic instead.
• The input dataset itself stopped updating at the connector. Fix the connector run before the dataflow.

Steps

1. Open the dataflow run history and read the failed run error, noting the transform step and column it names. Verify: the error names one transform and one schema element
2. Compare the input dataset current schema with the columns the dataflow expects, using the dataset preview. Verify: the renamed, retyped or missing column is identified
3. Edit the failing transform to use the new column name or handle the new type, and check later transforms for the same reference. Verify: no transform in the flow references the old schema element
4. Save and run the dataflow, watching it pass the previously failing transform. Verify: the run completes and writes a new output dataset version
5. Open the affected cards and confirm they render the new output data. Verify: cards show current values with no dataflow error banner
6. Add or review the dataflow failure alert so the next schema break notifies the owner before card viewers report it. Verify: the alert is active for the dataflow owner group

Why it happens

Schema changes propagate through named references, and dataflows are dense with them. The card layer failing loudly is useful, because it stops decisions being made on stale output, but the repair always belongs upstream. A schema change notice from the source team, plus a quick dataflow run, is the cheapest prevention available.

Domo dataflows, whether Magic ETL or SQL based, name input columns explicitly in their transforms. When an input dataset changes, a column renamed, a type changed, or a column dropped by the source system, the transform that uses it fails the run. The card error names the dataflow because Domo surfaces the upstream failure rather than serving silently stale output, which makes the card the messenger rather than the fault.

Field notes for Domo specifically. The dataflow run history, the dataset lineage view, and the card details together show the path from source to screen, and Domo surfaces upstream failures on cards deliberately, so the card is a reliable alarm even when it is not the fault. Schema changes from connected source systems are the dominant trigger in this family, which makes the connector change log, where one exists, part of the evidence. Note the dataflow version that failed, because edits during the incident can otherwise confuse the timeline.

Domo teams benefit from treating input datasets as contracts. When a source system team knows a dataflow depends on named columns, they can warn before renaming them, and the dataflow owner can stage the change. A simple dependency note on the dataset page, listing the dataflows and cards downstream, gives both sides the information a contract needs. Most schema breakage is not carelessness, it is invisibility, and lineage notes are the cheapest way to make the dependency visible before the change rather than after. One more check worth making standard on this class of failure is a short written close out in the ticket or change record, naming the layer that was wrong, the exact setting or reference that changed, and the test that proved the fix. Dashboard incidents repeat across teams because the repair knowledge stays in the head of whoever fixed it first, and the next occurrence starts from the symptom again. Three sentences of record turn a one off repair into a searchable answer, and they cost less than any single step of the investigation that produced them. Teams that keep these notes find their second occurrence of the same failure takes minutes, not hours.

Variants and edge cases

Domo dataflow failed after schema change card error fix

The direct phrasing matching the card message.

Domo Magic ETL transform column renamed run failed

The transform variant for Magic ETL flows.

Domo card shows dataflow error update transforms rerun

The repair sequence variant naming update and rerun.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstMlWviK6rvBdbC2kyF1x3g