# Data discovery portal so analysts stop asking which table to use

> Let analysts browse every catalog, schema and table, preview real rows safely, and fix descriptions in place, all without a workspace login.

- Workflow type: app
- Services: Databricks, Slack Bot
- Categories: Operations, Engineering
- Published: 2026-08-17

## What it does

- Browse every catalog, schema and table in your lakehouse from one screen, with keyword search across table and column names
- Open any table to see its columns and types, what it is for, who owns it, and when it was last updated
- Preview real rows through a read-only query with a strict row cap, so people can sanity check data without workspace access
- Let owners fix a table or schema description right where the question came up, so the catalog gets better as people use it
- Star the tables each person uses most, and message the listed owner in Slack with one click when something is still unclear

## What you'll need

- A Databricks workspace with Unity Catalog in use, and a login for it
- At least one SQL warehouse the preview queries can run on
- Owner and description fields filled in on at least some tables and schemas, so the portal has something to show
- A Slack workspace if you want the Ask the owner button to work

## Prompt

Build me a data discovery portal on top of Databricks Unity Catalog that analysts open whenever they are trying to work out which table to use, so they stop interrupting the data team to ask. Everyone shares one Databricks connection, so people who have no workspace access of their own can still find tables, read the documentation and see real rows.

The browse view walks the catalog top down. Use List Catalogs for the top level, List Schemas for the schemas inside a chosen catalog, and List Tables for the tables inside a chosen schema. Show the tree or breadcrumb path plus a list of tables with the description snippet and owner next to each one. Add a keyword search box that matches across table names and column names, so someone typing 'churn' or 'customer_id' lands on candidate tables. Cache the listings the handlers fetch so search feels instant and repeated browsing does not re-hit the API on every keystroke, and remember that Unity Catalog objects are addressed by dot separated full names in the form catalog.schema.table.

Clicking a table opens a detail page built from Get Table for that full name. Show the column list with each column's name, data type and column comment, then the table description, the owner, and when it was last updated. Timestamps come back as Unix epoch milliseconds, so render them as readable dates. If the description is empty, say so plainly and invite someone to add one rather than leaving a blank space.

The detail page has a Preview data button that shows real rows. Populate a warehouse picker from List SQL Warehouses and remember the last warehouse the person used. Preview runs a read only SELECT against the table through Execute SQL Statement with a row limit applied server side, defaulting to 100 rows with a hard ceiling of around 500. Execute SQL Statement is asynchronous for anything but the smallest results, so submit the statement, then poll Get SQL Statement until the state is SUCCEEDED, handle FAILED and CANCELED states with a clear message, and page long result sets in chunks. A warehouse that is asleep takes a moment to wake up, so show a waiting state rather than looking broken.

The preview handler has to be safe for non engineers. Build the statement server side from the table full name that the user picked in the UI, validate that full name against the catalog listing rather than trusting free text, allow only a single plain read with the row limit attached, and reject anything else outright. No inserts, updates, deletes, drops, multiple statements or arbitrary SQL typed by the user.

Owners can fix the documentation in place, which is how the catalog gets better as people use it. There is no update operation for tables in this catalog, so saving a table description runs a COMMENT ON TABLE catalog.schema.table IS '...' statement through Execute SQL Statement, escaping quotes in the text properly, then re-fetches Get Table so the page shows the saved value. Schema level editing is first class: saving a schema description or a new schema owner goes through Update Schema. When Databricks refuses an edit because the person's connection lacks permission on that object, surface that plainly instead of failing silently.

Each person can star tables as personal favourites that persist for them between visits. Store the starred full names per user in the app's own storage, not in Databricks, show a star toggle on both the browse rows and the table detail page, and give favourites their own view so people land on their usual tables first.

Finally, an Ask the owner button on the table detail page opens a prefilled Slack message to the listed owner. Resolve the owner value to a Slack user with Look Up User by Email, then send with Send a Message. Prefill a draft the person can edit before sending, naming the table's full name and asking the question they actually have, for example whether the table is still maintained or what a specific column means. If the owner cannot be matched in Slack, let the person choose a channel to ask in instead, and never block the rest of the page on that lookup.

## How to customize

- Change the preview row limit, or allow previews only for certain catalogs
- Pick a single SQL warehouse for everyone, or let each person choose their own
- Decide who is allowed to edit descriptions, and whether Ask the owner sends a direct message or posts in a shared data channel

## FAQ

### Do analysts need their own Databricks login to use this?

No. That is the whole point. The portal reads your catalog through one shared connection, so people who never get workspace access can still find tables, read the documentation and look at sample rows.

### Can someone accidentally change or delete data through the preview?

No. The preview only runs a plain read with a row limit applied before the query is sent, and anything that is not a simple read is refused outright. The only changes the portal ever makes are the description and owner edits you explicitly save.

### Where do the descriptions people write actually get saved?

Straight back into your catalog, not into a side database. Anyone looking at the same table in Databricks sees the description that was written in the portal, so the documentation improves everywhere at once.

### How is this different from the catalog browser Databricks already has?

The built in browser is excellent, but it needs workspace access and it is built for engineers. This is a stripped down, read only surface aimed at analysts, with search, previews, favourites and a one click way to ask the owner a question.

### Are starred tables shared with the whole team?

No. Favourites are personal, so each person builds their own shortlist of the tables they work with and sees it every time they open the portal.

Use this prompt in General Input: https://www.generalinput.com/prompts/data-discovery-portal-so-analysts-stop-asking-which-table-to-use