Edit Databricks tables in Excel
A wrong brand name, a missing category, a product that should have been deactivated last month. Workbook Connect lets the person who owns that data fix it in Excel and commit straight to your Databricks SQL Warehouse, validated against your Unity Catalog keys, with no notebook and no job run for a one-word change.
Your lakehouse, editable from the spreadsheet
Browse a catalog, open a table, correct a value, and commit. Excel and Unity Catalog stay in sync, with no export and no copy-paste in between.
The lakehouse is excellent at scale and terrible at typos
What Workbook Connect reads from Unity Catalog
Unity Catalog already knows the shape of your model: dim_product carries a category_id pointing at dim_category. Workbook Connect reads those declared primary and foreign keys and uses them to identify rows and to build the lookups your editors see.
An illustrative data model, not your exact schema.
Browse the catalog, open the table, edit the grid
Correcting dim_product without leaving Excel
Fix a brand, add a product, deactivate a discontinued one, and let the per-row status track every change. A category that does not exist is caught in the sheet, and nothing reaches the table until every row passes.
| Status | sku | name | brand | category | is_active |
|---|---|---|---|---|---|
| Changed | CF-250-BLK | Aeron Office Chair | Herman Miller | Seating | true |
| CF-118-OAK | Linnmon Desk 120cm | IKEA | Desks | true | |
| New | CF-560-WHT | Bekant Sit-Stand 160cm | IKEA | Standing Desks | true |
| Changed | CF-402-GRY | Markus Task Chair | IKEA | Seating | true |
| Needs fix | CF-771-BLK | Embody Gaming Chair | Herman Miller | Gamin | true |
| Changed | CF-630-NAT | Hilver Desk Bamboo | IKEA | Desks | false |
- Row 1: brand corrected from "HermanMiller" so this product finally groups with the rest of the brand in every downstream dashboard.
- Row 3: a new product added by the category owner. The category lookup only offers members that exist in dim_category, so the reference is valid before the commit is even attempted.
- Row 5: "Gamin" is not a member of dim_category. Databricks treats foreign keys as informational and would not reject this write itself, so the lookup and your validation rules in Excel are what catch it. The commit is blocked until this row is fixed, and nothing is written until every row passes.
An illustrative example of the editing workflow, not a product screenshot.
Guard rails where a lakehouse cannot provide them
Editing Databricks tables, answered
Tables registered in Unity Catalog that your grants already let you write to. You browse down the three levels you already think in, catalog then schema then table, and open the one you need. Unity Catalog is required: it is where the catalog and schema browsing comes from, and where the key metadata behind lookups lives. Tables still sitting in the legacy hive_metastore are not supported and need migrating first.
This is the important difference from a traditional database, and it is worth being precise about. Databricks keys are informational: they describe your model but the engine will not reject a write that breaks one. Workbook Connect reads those declared keys and turns them into real dropdowns in the sheet, so an editor picking a category is offered the members that actually exist rather than typing free text. Anything a lookup cannot cover, an authored validation rule can, and if any row fails the whole commit is blocked with the reasons listed. The guard rails sit in Excel because on a lakehouse that is where they have to sit.
No. That is the whole point of this workflow. The person who owns the attribute opens the table in Excel, types the correct value, and commits. The edit goes through your SQL warehouse as their own identity, and the next query against the table sees it. No notebook to run, no job to schedule, and no engineer pulled off their roadmap for a one-word fix.
Workbook Connect matches each changed row on its primary key and checks that the values you loaded are still the values in the table, so a row someone else has already changed is reported back to you rather than quietly overwritten. Note that Databricks has no rowversion or timestamp-style change marker, so the rowversion conflict detection used on SQL Server and Azure SQL Database is not available here. Declaring primary keys on the tables you plan to edit is what makes this work well.
The Workbook Connect add-in itself, plus the Databricks ODBC Driver version 2.10 or later, a free download from Databricks. The driver needs administrator rights to install and has to match your Office bitness, so 64-bit driver with 64-bit Excel. Workbook Connect checks for it on connect and links you to the correct download if it is missing. Serverless and pro SQL warehouses both work, with no difference in how you set things up.
No. Every read and write runs through your SQL warehouse as the identity that signed in, whether that is a personal access token, OAuth, or Entra ID with MFA. Unity Catalog permissions, auditing, and lineage apply to an edit made from Excel exactly as they apply to one made from a notebook. Workbook Connect creates no schema objects and nothing server-side, so it cannot hand anyone access your grants do not already give them.
Hand the lakehouse back to the people who own the data
Download Workbook Connect free, point it at a Unity Catalog table, and let the person who knows the value is wrong be the person who fixes it.