How to export clean values from ai/bi dashboard table that uses html formatted columns

[anmolhhns]

I'm working on Databricks AI/BI dashboard containing a native visualization; to achieve custom styling such as progress bars, the dataset SQL Generates HTML strings using expressions similar to:

CONCAT( '<div style="...">', CAST(value AS STRING), '</div>' ) AS formatted_value

The HTML renders correctly within dashboard table but when the data is exported the HTML tags are also exported along with it. Is it possible to export data without HTML tags?

[adnan_alvee]

The issue is that the HTML is stored as the actual string value. AI/BI dashboards render it when the column is configured as HTML, but exports use the underlying dataset value, so the tags are included. Databricks doesn’t currently provide an export option to render HTML visually while stripping it from CSV/Excel.


A workaround could be to return two columns:

SELECT
  net_sales,
  outlet,
  pct_sales,          -- clean numeric export value

  CONCAT(
    '<div style="background:#e5f7ef;height:8px;width:100px;">',
    '<div style="background:#00a972;height:8px;width:',
    CAST(ROUND(pct_sales * 100, 2) AS STRING),
    'px;"></div></div>'
  ) AS pct_bar_html
FROM sales_data;

Configure pct_bar_html  as Display type → HTML, and use pct_sales for downloads. Hide the raw column from the visual table if needed, or provide a separate export table/widget containing only clean fields.

If you already have the HTML column, a temporary cleanup is:

regexp_replace(formatted_value, '<[^>]*>', '') AS clean_value

[ThomazNeto]

Adding one option on top of the two-column approach above: depending on how attached you are to the exact progress-bar look, you may not need hand-rolled HTML at all anymore.

Table visualizations in AI/BI dashboards picked up richer native formatting in the 2026 updates — per-column conditional formatting, background color styling and color gradients. A background gradient on the pct column gets visually close to a bar, and since the cell remains a plain number, it renders styled AND exports clean — no second column, no regex, nothing to maintain when the template changes.

Worth a quick test before committing to the long-term HTML workaround: if native formatting covers your use case, the entire export problem disappears at the source. If it doesn't (e.g. you need a true proportional bar), the two-column pattern above is the right call — and a feature request for data bars would be well aimed, given how actively table formatting is evolving this year.