Saved Elasticsearch queries anyone on your team can run

Build me a saved query library that turns our Elasticsearch cluster into something the whole company can self-serve from. Right now our engineers rewrite the same five queries every week, and everyone else files a "can you pull this for me" request. This app is the surface that replaces both.

The main view is the library itself: every saved query rendered as a card showing a plain-English name, a one-line description of what question it answers, who owns it, which data it reads, and the parameters it takes. Cards are searchable and filterable by owner and by data source. This is the page people land on, so it has to be scannable by someone who has never written a query in their life.

Opening a card shows a simple form, never query syntax. The standard fields are a date range picker, a service dropdown, a customer ID box, and a status dropdown, but each saved query declares which parameters it actually takes and the form renders only those. Pressing Run executes the Elasticsearch Search Documents (Query Index) operation against that query's target index with the parameter values filled in, and renders the matching rows as a sortable table whose columns come from the fields the query returns. Above the table, show the total using the Count Documents operation run with the same filters, so people see something like "showing 50 of 3,412" rather than an unqualified page of rows.

Put the generated query behind an Advanced toggle, collapsed by default. Engineers need to audit exactly what runs before they will trust the library, but nobody else should ever see it. Do the same with failures: if a run breaks, say so in plain language on the surface and keep the raw error inside Advanced.

Every result view has a Share results button that posts a summary to a Slack channel using the Slack Bot Send a Message operation: the query name, the parameter values that were used, the total count, and the first handful of rows formatted readably. Let the person pick the channel.

The saved queries themselves live in their own Elasticsearch index inside the same cluster. Create it once on first run with the Create Index operation, with an explicit mapping. Each saved query document holds a name, a description, an owner, the target index, the query body with placeholders for its parameters, the parameter definitions (name, label, type, default value, whether it is required), a created date, a run count, a last-run timestamp, and an active or retired status. New entries are written with the Index (Create or Replace) Document operation, and edits use Update Document.

When someone defines a query by hand, an index picker built from the List Indices operation shows the data sources available along with doc count and size, so they can tell a live source from a leftover. Choosing one calls the Get Index Schema (Mapping and Settings) operation and lists the fields that actually exist with their types, so nobody has to guess at a field name. Let an admin restrict which indices appear in that picker.

The headline feature is a "Describe what you need" button that starts a background agent, and it deserves the most attention in the build. The person picks a data source and types what they want in plain English, something like "failed checkout attempts by payment provider last week". The agent then does the work an engineer would do. It reads the target index mapping with Get Index Schema to learn the real field names and types. It samples real documents with Search Documents to learn what the values actually look like, because a mapping tells it there is a status field but only real rows tell it whether a failure is recorded as "failed", "declined", or a numeric code. It drafts a query, test-runs it with Search Documents, and inspects what came back: zero rows or obviously wrong rows means the guess was wrong, so it adjusts the field names, the value matching, or the time field and tries again. It keeps that draft-and-test loop running until the query returns sensible rows.

When it has something that works, the agent decides which parts of the request should become parameters rather than hard-coded values. "Last week" becomes a date range parameter, "by payment provider" becomes a provider dropdown, and so on, so the saved entry is reusable instead of a one-off. It then writes the entry into the library index with Index (Create or Replace) Document, giving it a plain-English name and a description of the question it answers. Show the agent's progress in the app while it runs, in plain language, so the person can watch it reading the structure, sampling records, and testing. The finished entry lands in the library marked as needing review, with its test rows shown, so the person who asked can rename it, correct the description, and confirm before it goes live for everyone. The agent must only ever write to the saved query library index, never to any other index in the cluster.

This agent is the reason the library grows. Every time somebody asks a question that is not already in the library, the answer becomes a permanent, named, parameterized entry the next person can simply run, without an engineer ever writing a query.

Track a run count and a last-run timestamp on every saved query, incremented with the Update Document operation each time someone runs it. Surface both on the card, and add a view sorted by least recently used so dead queries can be spotted and retired. Retiring hides an entry from the main library without deleting it.

Throughout the interface, use ordinary words rather than Elasticsearch vocabulary. Say "data source" or "table" rather than "index", "record" or "row" rather than "document", and "date range" rather than anything about ranges or filters. The phrases "Query DSL", "bool filter", and "aggregation" should never appear anywhere a non-engineer can see them. The entire point is that someone in finance or support can pull their own numbers without learning what an index is.

Two technical notes for the build. Page results with search_after and a stable sort that includes a tiebreaker field, not deep from and size paging, because standard pagination caps at 10,000 by default and this library will hit that on log-shaped indices. And pass track_total_hits when the total needs to be exact, otherwise hits.total silently flattens at 10,000 and the count above the table will be wrong. Elasticsearch is authenticated per cluster with a user-supplied base URL and key, so never hard-code a host anywhere in the app.