Brickster Newsletter

Your dashboards can switch sides

Importing Power BI and Tableau files into Databricks became generally available this week. It shipped, and the docs are refreshingly honest about where it struggles. We read all of them so you can skip to the parts that bite.

The headline first. On August 20, importing reports and data models from Power BI and Tableau with Genie Code, the chat agent inside Databricks that builds dashboards on request, became generally available on AWS, Azure and Google Cloud. Generally available, GA for short, is the stage where a feature leaves preview and Databricks stands behind it for production use. The command is /importBI: you hand Genie Code a dashboard file, and it builds a Databricks AI/BI dashboard that sets out to replicate your visuals, wired to metric views. Metric views are the catalog objects that hold the business logic: the definitions of revenue, margin, and whatever else your company argues about in meetings.

One caution: the notes for this feature have churned almost weekly since early July, so re-check the docs before quoting anything.

The first practical surprise sits in the file picker. For Power BI it wants a .pbit template, not the .pbix you actually work in, and a template carries no data. Which explains the best practice in Databricks’ own docs: always attach a screenshot of the original, because Genie Code “migrates best when it can validate layout and numbers against a high-quality reference image.” An importer that asks for a photo of the thing it is importing is telling you, politely, how much of the checking still belongs to you. Tableau comes in as .twb, .twbx, .tds or .tdsx, and direct uploads cap at 100 MB. Bigger files still get in, they just have to be staged in Databricks storage first and referenced from there.

The second surprise is a toggle. None of this runs until partner-powered AI features are enabled for both the account and the workspace, the admin switches that allow features backed by outside AI models. Plenty of security teams keep those off on purpose. Check yours before you promise anyone a demo.

The third is what happens after the import succeeds. Your new dashboard leans on metric views, and metric views keep their own rules. In a query they cannot be joined to anything else, and an attempt fails with METRIC_VIEW_JOIN_NOT_SUPPORTED. In plain SQL you read a measure through the MEASURE() function rather than summing it yourself. The sharpest edges sit one page over, in BI compatibility mode, the bridge that lets outside tools like Tableau keep querying those same metric views. There, some tool features quietly generate joins on their own, so things can fail that you never wrote. SUM, COUNT, MIN and MAX are all rewritten to the measure’s own definition, so all four return the same number. And for non-additive measures, the ratios and percentages and anything involving DISTINCT, the docs say grand totals “might display incorrect values.” None of this is hidden. It is documented, plainly, on pages you will want open while you check the result. One more: imported metric views live inside their dashboard until you promote them into Unity Catalog, the platform’s shared library of data assets, for anything else to use.

A last piece of context makes this GA more interesting than a feature note. Back in April, Microsoft removed the BI compatibility mode option from the Power BI connector to Azure Databricks, the option that let Power BI query metric views directly. Reports that used it no longer function, the sanctioned path is now a hand-written native query, and Databricks’ docs point readers at a post on Fabric Ideas, Microsoft’s feature-request board, where you can vote for its return. So the door from Power BI into Databricks got wider this week, four months after the door in the other direction got narrower. Whether to walk through it depends on where your dashboards should live, and “where they already are” is sometimes the right answer.

The bundle engine flip arrives with a seatbelt

Last week we flagged August 26 as the date Databricks CLI bundle deployments switch engines, from Terraform to the new direct engine. The engine is the machinery that turns your bundle’s config files into actual jobs and pipelines in the workspace, and bundles managed inside the workspace already switched on July 24. The calmer detail, published by the CLI maintainers this week: the default flips with CLI v1.14.0, which had not shipped as we went to press, and if migration hits any error your bundle simply stays on Terraform. If your CI, the pipeline that runs deployments automatically, pins the CLI version, nothing changes for you until you bump it. Setting bundle.engine: terraform in databricks.yml, the bundle’s settings file, opts you out either way. The one behavior genuinely worth learning: under the old engine, deleting a field from databricks.yml left the deployed value alone. Under the new one, deleting it resets the value to the resource’s default. If you want a value to survive, write it down explicitly.

Databricks Runtime 13.3 LTS ran out of support on Saturday

Three years to the day after its release, Databricks Runtime 13.3 LTS, a long-term-support version of the engine that clusters and jobs run on, reached end of support on August 22. Nothing is scheduled to break: end of support is not a kill switch, and existing jobs keep running. What stops is fixes, patches and support, and the version disappears as an option when you create new compute. In our experience it is always the oldest, most load-bearing jobs that are pinned to the oldest runtime, precisely because nobody dares touch them. The announcement is not news, only the date is. That is exactly why it makes this list: deadlines do not send a second reminder, and this one just went from someday to overdue.

Document extraction grew a precision mode

Two related items. Databricks published a Document Intelligence post on August 18, and a day later precision mode went GA for ai_extract, the SQL function that pulls structured fields out of messy documents. Precision mode targets the hard cases: long documents, high-volume outputs, and schemas that need reasoning, like pulling hundreds of line items off invoices or contract terms scattered across a filing. Our standing advice applies double here: run a costed sample before pointing any extraction mode at a million documents. These functions are metered, billed by what you run through them, and the meter is easiest to forget while the demo is impressing people.

Access control learned two new tricks

Role-based access control went GA on August 19: people assume a role and work with that role’s permissions only, instead of everything they have ever been granted, which is how you keep one client’s analysts out of another client’s tables when the same person serves both. Two days later, attribute-based policies picked up context attributes, in Beta: row filters and column masks, the rules that hide certain rows or blank out certain columns depending on who is asking, can now key on which client application is calling and whether it is acting on someone’s behalf. That is aimed squarely at telling an agent apart from the human it acts for. Neither changes anything until you write the unglamorous policies that use them.

Quick links this week:

→ brickster.ai/articles: The Partner Champion path from the inside.

→ brickster.ai/digest/week: The full weekly digest behind section two, with every source we read.

→ brickster.ai/assistant: Ask it whether anything in this issue applies to the setup you are running.

📊 Wondering which of your dashboards would survive the trip to Databricks?

The Brickster Assistant searches our full archive and answers with citations.

Enjoying the Brickster Newsletter?

Forward this to a colleague who works with Databricks.