Give your team Looker numbers without buying more seats

Build me a self-serve metrics portal on top of Looker for the people on my team who do not have a paid Looker seat. Today an ops manager, a CS lead, or a sales rep needs three numbers a week and cannot justify a licence, so they ping an analyst every time. This app should let an admin curate a catalog of approved Looks and dashboards, and let everyone else browse that catalog, set filters, and read live results themselves. The audience is non-technical, so the interface should feel like picking a report off a shelf, not like building a query.

Admin catalog page. Only admins see this. It searches Looker with Search Looks and Search Dashboards so an admin can find content by title or folder, and add individual Looks and dashboards to the curated catalog. Each catalog entry stores the Looker id, a friendly display name and description the admin can override, and a section label such as Sales, Support, or Finance for grouping. For a dashboard entry, call Get Dashboard to pull its title and tiles, and Get All Dashboard Filters to read the filters it exposes, so the admin can choose which of those filters viewers are allowed to change and set default values for the rest. Admins can reorder, rename, and remove entries. The curated catalog lives in the app's own storage, not in Looker.

Viewer home. Everyone else lands here. It shows the curated catalog grouped by section, with search across the friendly names and descriptions. Above the catalog, show the signed-in viewer's pinned favorites and their recently run list, each entry deep-linking back into the report with the filters they last used. Favorites and recents are stored per viewer, so what one person pins never shows up for anyone else.

Report view. When a viewer opens a catalog entry, render the filters the admin exposed for it as friendly controls, using date pickers for date filters and dropdowns where the filter has a fixed set of values, prefilled with the admin's defaults. When the viewer hits Run, a server handler executes the query and renders the result twice: as a sortable table and as a chart chosen to fit the shape of the data, such as a line for a time series and a bar for a category breakdown. For a Look, use Run Look with the json result format. For a dashboard tile or a filtered query, use Run Inline Query with the json result format, or Run Query when running a saved query id. Because some of these reports are heavy, run anything that may be slow through Run Query Async and poll Get Async Query Results until it completes, keeping a loading state on screen rather than timing out. Show the row count and the time the query ran so nobody wonders whether they are looking at stale numbers.

Sharing actions. From any result the viewer gets two buttons. Post to Slack formats a snapshot of the result, the report name, the filters that were applied, and the headline figures, and sends it to a channel the viewer picks with the Slack Bot Send a Message operation, using List Channels to populate the channel picker. Send to spreadsheet pushes the underlying rows into a reporting spreadsheet with the Google Sheets Append Values operation, stamping each row with the report name, the filter values, and the run timestamp so appended history stays readable. Let an admin restrict which channels and which spreadsheet are available.

Explain these numbers. Put a button next to the chart that kicks off a background agent. The agent re-runs the current query for the selected period, runs it again for the immediately preceding period of the same length, compares the two, and writes a short plain English read of what moved, by how much, and what most likely drove it, calling out the largest contributing segments or rows rather than just restating totals. It should write its output back into the app so the explanation renders in a panel right beside the chart, with a timestamp and the two periods it compared. Show a clear in-progress state while the agent works, and keep the last explanation visible so a viewer can reopen the report later and still see it.

The most important rule: the portal must never expose Looks or dashboards outside the curated catalog. Every server handler that runs a query has to check the requested id against the approved catalog first and refuse anything else, rather than trusting an id sent from the browser. Everything the portal does is read-only against Looker, with no ability to create, edit, or delete Looker content. The whole point is controlled read-only access for unlicensed staff, so lean toward being restrictive: if an admin has not approved it, it does not exist as far as this app is concerned.