Skip to content
Download
FOR DATA ENGINEERS

Workbook Connect for data engineers

Stop being the data-entry desk for everyone else's reference tables. Hand master and reference data upkeep back to the people who own it, in Excel, validated and committed to your database, while your pipelines stay the source of truth.

Download free

Let the business edit, without a pipeline for it

A steward edits a dimension in Excel and commits. The rows land in your table directly. No staging load, no CSV round-trip, no ticket in your queue.

EXCELDATABASE

The reference-data tax on your week

You did not get into data engineering to run UPDATE DimProduct SET UnitOfMeasure = 'ROLL' WHERE SKU = 'MX-4471' because someone in operations noticed a wrong value. Yet that is half the queue: a new SKU to insert, a category to rename, a mapping table to extend, a record to deactivate. Each one is a context switch, a quick script written under pressure, and a write that bypasses the validation a real load would have done. The person who actually knows the correct value is sitting in the business with no safe way to make the change, so it routes through you, and the dimension drifts a little more every time.

The tables this actually touches

Reference and master data is usually a small dimension keyed to an even smaller lookup. A product is filed under a category, and the foreign key is what keeps every row honest. Workbook Connect edits exactly these tables and uses the FK to drive an in-cell lookup, so a steward can only pick a category that exists.

∞1CategoryIDDimProductCategoryCategoryIDPKCategoryNameIsActiveDimProductProductIDPKSKUProductNameCategoryIDFKUnitOfMeasureIsActive

An illustrative data model, not your exact schema.

Hand back the keyboard, keep every guardrail

You set DimProduct up once as a Configurator. CategoryID becomes a dropdown sourced live from DimProductCategory, so "Packaging" is picked, never typed. A filter scopes the steward to active rows in their own product line. ProductID maps as the primary key but stays hidden, surrogate noise the business never needs to see. Then you save it, and that configuration is shared to the team automatically on connect. Every steward opens an identical, guard-railed sheet. When they pick a category, they get real values from the lookup. When they add a SKU, your unique-key rule is already watching. Self-service stops being a synonym for "fix it later".

A product dimension, as a steward edits it

Six rows mid-edit. The per-row status tracks every change, foreign-key lookups keep categories valid, and validation flags the two rows that would have quietly corrupted the dimension, blocking the commit until they are fixed.

ProductMaster.xlsx - DimProduct
StatusSKUProduct nameCategoryUoMActive
ChangedMX-4471Pallet wrap 500mmPackagingROLLY
MX-4472Pallet wrap 750mmPackagingROLLY
NewMX-9008Thermal label 4x6LabelsBOXY
Needs fixMX-9008Thermal label 4x6 (dup)LabelsBOXY
Needs fixMX-3120Stretch hood filmPakagingKGY
ChangedMX-2200Edge protector 1.2mPackagingEAN
Commit Validated, then written to dbo.DimProduct
  • Row 1: someone in operations corrected the unit of measure from EA to ROLL. Tracked as a change, committed under their own database login.
  • Row 3: a brand-new SKU added by the data steward. The Category lookup only offered values that exist in DimProductCategory, so the foreign key is valid before commit.
  • Row 4: SKU MX-9008 already exists, so the unique-key validation rule flags it. The commit is blocked until this row is fixed, and nothing reaches the table until the duplicate is resolved.
  • Row 5: category "Pakaging" is a typo that does not resolve against DimProductCategory. The foreign-key lookup flags it before it can orphan the row.
  • Row 6: deactivated rather than deleted, so historical fact rows that reference it keep their lineage.

An illustrative example of the editing workflow, not a product screenshot.

Validated, transactional, and nothing changes server-side

Before a single row reaches DimProduct, the rules run in the sheet: the SKU must be unique, the category has to resolve against DimProductCategory, and a deactivation flips IsActive rather than deleting a row that history still points at. The per-row status marks each line new, changed, or flagged for deletion, and if any row fails the commit is blocked and nothing is written. The failing rows stay in the sheet with their reasons, so you fix them and commit again, and then every row is written together in one transaction, under the steward's own database login, with optimistic concurrency catching the case where two people touched the same SKU. And it does all of this against your existing tables: no triggers, no staging objects, no schema changes. Your downstream pipelines just wake up to a cleaner, current dimension.
testimonials

What our users think

"We used to write one-off scripts every time the business wanted to update reference data. With Workbook Connect they edit it themselves in Excel, and everything stays in sync with the database. It freed up an enormous amount of my time."
Benoit ZwartjesData Engineer

What data engineers use it for

Works with your database

FAQ

Data engineers, answered

No. Workbook Connect reads and writes your existing tables. It creates no triggers, no staging tables, no shadow columns, and no server-side objects of any kind. The per-row status (new, changed, flagged for deletion) lives in the workbook, not in your database. If you drop the add-in tomorrow, your schema is byte-for-byte what it was before.

You configure each table once: which columns are visible, which rows are in scope via a filter, how the primary key maps, and which foreign keys become dropdown lookups. Then your validation rules run in the sheet before any write (unique SKU, non-null category, a value in an allowed set), and if any row fails, the commit is blocked and nothing is written until you fix it. Roles split Configurator from User, and everything is enforced for every user on every connection, including the free plan. Authoring those rules in the Validation Designer and managing access are Pro features.

Optimistic concurrency. When someone commits, Workbook Connect checks whether the underlying row changed since they loaded it. If the steward and operations both edited UnitOfMeasure on MX-4471, the second commit is flagged as a conflict instead of silently winning. They reload, see the current value, and decide, rather than discovering it in a report three weeks later.

No. Workbook Connect validates the whole sheet in Excel first. If any row fails, the commit is blocked and nothing is written, so you never get a half-applied dimension update. The failing rows stay in the sheet with their reasons, ready to fix and re-commit, and once every row passes they are all written together in a single transaction.

Your existing methods: Entra ID interactive with MFA, Entra ID username and password, Service Principal, Managed Identity, Windows Integrated, SQL auth, and Default Azure Credential, all over TLS 1.2 or higher. There is no shared service account smuggling in extra rights. Each person connects as themselves and can only touch what your database already grants them. If a user lacks UPDATE on DimProduct, the commit fails the same way it would from SSMS.

Today: Azure SQL Database, SQL Server, Fabric SQL Database, and Microsoft Fabric Warehouse. PostgreSQL, Databricks Lakebase, and Databricks SQL Warehouse are coming soon with early access.

No. A Configurator sets up the table once (lookups, filters, key mapping, hidden columns) and that configuration is shared to the team automatically on connect. Every steward opens the same guard-railed sheet, so you maintain one definition instead of forwarding a templated workbook around.

Get out of the data-entry business

Download Workbook Connect free, point it at one dimension table, and hand the upkeep back to the people who own the values. You keep the schema, the permissions, the validation, and the transaction. They get a sheet that will not let them break it.

Download free