Databricks Apps Development

Once your data is governed in a lakehouse, the next request is always an interface. Someone needs to review records, approve exceptions, adjust a forecast or look something up, and a dashboard cannot do it because a dashboard cannot write back.

The usual answer is a separate web application: its own hosting, its own login, its own copy of the credentials, and its own security review. Databricks Apps removes most of that by running the application inside the workspace, next to the data, using the governance that already exists.

For internal tools that read and write governed data, this is now the shortest defensible path from requirement to something people can use.

What this is good for

The pattern fits a specific and common class of tool.

Review and approval queues. Records that need a human decision before they move on, with the decision written back to a governed table and attributable to a person.

Data quality consoles. Surfacing the rows that failed a rule so somebody can fix them, rather than emailing a spreadsheet of exceptions.

Forecast and planning adjustment. A model produces a baseline, a planner overrides specific lines with a reason, and the override is stored rather than lost in a spreadsheet.

Lookup tools. Internal search over governed data for staff who should never be given a SQL editor.

Why running it inside the workspace matters

Three practical consequences, and they are the whole argument.

Permissions are inherited rather than reimplemented. The app sees what the signed-in user is allowed to see, because Unity Catalog already decided that. Nobody writes a second authorisation layer and nobody gets it subtly wrong.

There are no credentials to distribute. The application is not holding a database password in an environment variable somewhere, which removes an entire category of incident.

And the data does not move. No extract, no sync job, no second copy drifting out of date, no questions about where the copy lives.

Genie, and where natural language fits

Genie lets people ask questions of governed tables in plain language. It is genuinely useful and it is not a replacement for a designed interface.

It works well when the question is exploratory and varies every time, when the person asking understands the domain, and when the tables have been described properly, which is the part that decides whether it performs. It works badly as the primary route for a repeated operational task, where a purpose-built screen is faster and less ambiguous.

The sensible arrangement is both: an app for the daily operational job, Genie alongside it for the questions nobody anticipated.

The limits, stated plainly

This is a pattern for internal tools, not for customer-facing products. The audience is people who already have workspace access.

Interfaces are functional rather than elaborate, which suits an operations console and does not suit a consumer application. And it ties the tool to the platform, which is a reasonable trade when the data is already there and a poor one if you might move.

What building one actually involves

Less than people expect, provided the tables underneath are in order.

The application itself is usually a small amount of Python rendering an interface over governed tables, deployed into the workspace. There is no separate hosting to provision, no credential management, no authorisation layer to write, and no security review of a new external service. Those absences are most of the saving.

The work concentrates instead on defining the job precisely and confirming the tables can support it. An app that reads or writes a table nobody has cleaned inherits every problem in that table, and surfaces it to a user who will reasonably blame the app.

Where a spreadsheet is still the right answer

Worth saying, because building something is not always the correct recommendation.

If a task runs a few times a month, involves one person, and does not need an audit trail, a spreadsheet is faster and cheaper and there is no shame in it. The case for an app arrives when several people need the same view, when the decision has to be attributable, or when the spreadsheet has started drifting away from the governed data and producing a second version of the truth.

That last one is the usual trigger, and it is worth acting on when it appears rather than after two teams have built conflicting reports.

Working out whether you need one

Two signals say yes. Someone is maintaining a spreadsheet that duplicates governed data and has started to disagree with it. Or a decision needs to be attributable and currently is not.

If neither is true, you may not need an app, and I will say so. Where one is true, the build is usually small, provided the tables underneath are already in order. That is the thing worth checking first.

What the engagement includes

A defined internal tool. Scoped to one job a person actually does, built to do that job well rather than to be a general interface.
Permission inheritance. The app respects Unity Catalog, so a user sees exactly what they are entitled to with no second authorisation layer to get wrong.
Write-back with attribution. Where the tool records decisions, they are written to governed tables with the person and timestamp attached.
Genie alongside, where it helps. Natural-language querying configured against properly described tables, for the exploratory questions an app cannot anticipate.
Handover documentation. How the app is deployed, how to change it, and what it assumes about the tables underneath.

How the work runs

Define the one job. What task this replaces and who does it. Tools built without this become general interfaces nobody uses.
Confirm the tables underneath. The app is only as good as the governed tables it sits on. Gaps get fixed first.
Build against inherited permissions. No second authorisation layer, no stored credentials, no copied data.
Add write-back with attribution. Decisions recorded to governed tables with the person and time attached.
Document and hand over. Deployment, extension and assumptions, written for your team.

Proof

These sit on top of the medallion layers, and the awards manufacturer case study shows the full stack in one place.

Talk about your situation

The first conversation is short and mostly questions. Get in touch and tell me what you are trying to fix. Or see how this is priced.

Frequently Asked Questions (FAQs)

What are Databricks Apps?

Applications that run inside a Databricks workspace, next to the governed data, rather than as a separate web application with its own hosting and credentials. They inherit Unity Catalog permissions, which means the interface shows each user exactly what they are entitled to see without a second authorisation layer.

When should I build a Databricks App instead of a dashboard?

When people need to write something back. Dashboards read. If the job involves approving, correcting, overriding or annotating, a dashboard cannot do it and the alternative is usually a spreadsheet that drifts away from the governed data.

What is Databricks Genie?

A natural-language query layer over governed tables, so people can ask questions in plain English rather than writing SQL. It performs in proportion to how well the tables are described, which is why the metadata work matters more than the feature itself. It complements a purpose-built app rather than replacing one.

Can these be customer facing?

No, and it is the main limitation worth knowing. The pattern is for internal users who already have workspace access. Customer-facing products need a conventional application, which is a different build with different security requirements.

Do users need a Databricks licence to use the app?

They need workspace access, which is what makes permission inheritance work and is also the main limitation. This pattern suits internal users who are already in the platform. If the audience is customers or partners without workspace access, a conventional application is the right answer instead.