> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/kaiya/kaiya-apps/live-data-in-apps.md). # Live data in Apps An App can be **precomputed**, **live**, or **mixed**. * **Precomputed:** every number comes from data captured at the last refresh. * **Live:** every cell queries the source when you use it, so the numbers are always current. * **Mixed:** some cells query live, the rest use data from the last refresh. Because a live App queries the source when you filter, you can slice the data without regenerating the app. ### **How live querying works** When someone changes a filter in a live App, the App does not run the query itself. It sends the name of the query and the filter values you chose (never the SQL) to Tellius. Tellius fills in the values, applies your data permissions, and runs a read-only query against the source. The rows come back and the cell redraws. Two things follow from this design, and both matter: * The App in your browser never holds the SQL and never connects to the data platform directly. Every live interaction is a checked call through Tellius. * Your data permissions are applied at the moment the query runs, for whoever is viewing — never for whoever built the app. ### **What you see in a live App** When you open a live App, the difference from a precomputed one shows up in three places: the filter bar, how cells load, and how quickly they respond. **The filter bar:** A live App has a filter bar with dropdowns for values (Region, Brand, Payer) and a picker for date ranges. The dropdown options are loaded from the source rather than saved into the App, so the lists are always current and show only the values your permissions allow. **Loading:** Cells fetch their data as soon as the App opens, so you see numbers immediately and don't have to choose a filter first. Date filters start on a wide default range, and value filters start unset, resolving to everything you're permitted to see. **Responding to filters:** When you change a filter, only the cells that depend on that filter re-query; the rest stay as they are. Data and dropdown lists load independently, so a cell never sits waiting on a dropdown to finish. And, if you go back to a filter combination you've already used in the same session, it renders instantly, because the App reuses the results it already has. ### **What live filters can and cannot do** Only the values in the filter are interactive. What a cell measures and how it groups were decided when the app was built. **Supported** * Value filters, such as *Region*, *Brand*, or *Payer* (one value or a list) * Time and date-range filters * Filters that drive several cells at once * Whole-App live, or a mix of live and precomputed cells * Live cells inside older versions of an App * Remixing a live App **Not supported** * Drill-down - a live cell cannot regroup by a different column * Changing which measures or dimensions a cell shows * Re-running calculation or summary steps when you interact * Typing free text to filter on values that aren't listed {% hint style="info" %} *"Show me this by region instead"* is an edit to the App, not a filter. Ask Kaiya to change it. {% endhint %} ### **App types and badges** Every App, and every version of an App, is one of three types, shown so nobody has to guess whether a number is current. | Type | Meaning | How it's shown | | --------------- | ------------------------------------------------------------- | ------------------------------------------------ | | **Live** | Every cell queries the source. | One badge in the App header. No per-cell badges. | | **Mixed** | Some cells are live; the rest use data from the last refresh. | A Live pill on each live cell only. | | **Precomputed** | All data comes from the last refresh. | No badge of any kind. | {% hint style="info" %} The App's plan card carries the same signal before the App is built. Because the type is stored per version, opening an older version shows that version's behaviour, not the current one's. {% endhint %} ### **Making an existing App live** A precomputed app can be converted in conversation, with no rebuild: * **"Make this app live"** converts the whole app. Its existing queries are reused and pointed back at the source, and interactive filters come from the key dimensions already in the plan. * **"Make just the *****support-impact***** panel live"** converts one section, producing a mixed app. {% hint style="warning" %} Sections whose data comes from calculation steps rather than a query cannot be converted and stay precomputed. On Apps built without section-level structure, a request for a single section converts the whole App instead. {% endhint %} ### **Editing a live App** Presentation changes are cheap; new data is not. * Restyling, relabelling, rearranging, or building a new cell from data the App already fetches leaves the existing queries untouched. * Asking for a metric, dimension, grouping, or filter column the App doesn't already fetch creates new queries. Existing cells keep working, and the new cell gets its own live query. ### **Refreshing a live App** * Refresh re-captures data for precomputed cells. * A fully live App has nothing to re-capture, because every cell already queries the source when you use it. Refreshing one records a successful refresh and updates the timestamp without re-running anything. * A mixed App refreshes its precomputed half normally. * If you refresh a live App and nothing appears to change. It's because the App was already current. ### **Data permissions in live Apps** Data permissions in a live app work differently from a shared file, and the difference is deliberate. * Permissions are resolved for the person viewing the App, at the moment the query runs; not for the person who built it. * The same live App therefore shows different totals to people with different permissions. This is the intended design. * Filter dropdowns are filtered the same way, so you are never offered a value you cannot query. * If permissions cannot be resolved, the cell shows an error rather than unrestricted data. * If you have no permitted values for a filter, that cell shows an error instead of someone else's data. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.tellius.com/kaiya/kaiya-apps/live-data-in-apps.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.