Current topics · Practical interview preparation
Excel and Databricks: Build a Governed Reporting Workflow
Practise grain checks, refresh validation and safe separation of spreadsheet analysis from database write-back.
16 September 2026 · Prakhar ShrivastavaA spreadsheet connected to a governed data platform still needs clear definitions, validation and ownership. Treat the connection as one part of reporting rather than a guarantee that every pivot table is correct.
Why this matters this week
Databricks announced general availability of its Excel Add-in on 10 September 2026, including governed data access and write-back capabilities. Consult the product documentation for installation and permissions. This is an independent reporting exercise, not a deployed add-in test. Read the announcement.
Define the grain first
A synthetic extract has three rows: order 201 has two lines worth $60 and $40; order 202 has one line worth $50. Columns are OrderID, LineID and LineRevenueUSD. The grain is one order line. Revenue is $150, but there are two orders, not three.
An ordinary count of populated OrderID values returns three. Dividing revenue by that count produces $50. Average order value is actually $150 divided by two distinct orders: $75. Provide an order-level extract or a correctly defined distinct-order measure before distributing the workbook.
Prepare a reliable extract
This self-contained SQL works in DuckDB and PostgreSQL. It aggregates lines to orders before calculating the average. It is a learning query, not connector configuration.
WITH lines(order_id, line_id, revenue_usd) AS (
VALUES (201, 1, 60), (201, 2, 40), (202, 1, 50)
), orders AS (
SELECT order_id, SUM(revenue_usd) AS order_revenue_usd
FROM lines GROUP BY order_id
)
SELECT COUNT(*) AS order_count,
SUM(order_revenue_usd) AS revenue_usd,
AVG(order_revenue_usd) AS average_order_value_usd
FROM orders;
Expect two orders, $150 revenue and $75 average order value. Add a $30 line to order 202: revenue becomes $180, order count stays two and average order value becomes $90. This catches a mismatch between row count and business entities.
Make refresh state visible
Include the source, reporting cutoff, last successful refresh, currency and metric definition. A refresh attempt is not necessarily successful. If it fails, label retained data with its last successful timestamp rather than allowing an old report to appear current.
Compare workbook totals with the source query under identical filters and identity. Check hidden sheets, pivot filters and cached results for different reporting periods. Test recipient permissions where possible: the creator’s access does not establish what another user can query.
Separate analysis from write-back
Start this exercise with read-only access. If a workflow requires database updates, define valid fields, allowed values, approvals, audit history and conflict handling. Saving a workbook is not necessarily equivalent to a validated database transaction.
Two analysts might edit the same forecast from different starting versions. Detect that conflict instead of silently accepting the last upload. Keep a recoverable record of the previous value and the authorised change.
Interview practice
“The spreadsheet and warehouse show different average order values. What do you check?” Start with grain and denominator, then filters, freshness, access scope and metric definitions. Reinstalling a connector should not be the first response to a business-logic mismatch.
Continue with order-line modelling and reconciliation.
