Tim Jacobs - Hi team, we seem to have an issue ...
# dev-help
t
Hi team, we seem to have an issue with embedded liveboards, parameters and filters. We use a parameter passed by the embedding app, which filters the data, we then have an additional filter for the user to interact with. For some reason the filter doesn't update to correspond with the input on the parameter. This works fine within the ThoughtSpot app. Screen shots attached. The TS Filters screenshot shows within the TS app with correct filters for department, the embedding app filter screenshot shows incorrect. Note the table viz behind which displays correct data in both. https://cdn.discordapp.com/attachments/1143209464875462756/1506256082778198026/Embedding_App_Filters.jpg?ex=6a0d99cb&is=6a0c484b&hm=6761d41fc7de65a6dc7d537838434cd330315d515b2e36a31864664787c0d906& https://cdn.discordapp.com/attachments/1143209464875462756/1506256083142971492/TS_Filters.jpg?ex=6a0d99cb&is=6a0c484b&hm=7b6b5b58833887b6109d2fca0e82d35f35a59e71f9a4acb9ad34dd6209273662&
a
message has been deleted
s
What you’re describing is consistent with runtime filter/parameter context affecting data results, but not fully constraining the filter value picker UI in embed. From your screenshots: - The viz data is correct (so your passed parameter/runtime filter is being applied to query results). - The interactive filter picker shows values from another warehouse in embed (so the picker list is not being scoped the same way as in full ThoughtSpot app view). Most likely cause: the filter dialog is showing unscoped values unless “filtered values only” behavior is active in that context. I can see this difference in your screenshots too (full app shows “Show unfiltered values” toggle in the filter modal; embed screenshot does not). That UI difference strongly suggests a different filter-chip experience/config between app and embed. ### What to verify first 1. Use runtime filter operator/value exactly - For warehouse scoping, use
RuntimeFilterOp.EQ
(single) or
IN
(multi), and exact column name mapping. 2. Confirm same Liveboard experience flags - If you use compact header settings in embed, check whether filter-chip behavior differs there. 3. Check if irrelevant chips are hidden in tabbed Liveboards -
isLiveboardCompactHeaderEnabled
+
hideIrrelevantChipsInLiveboardTabs
can change what users see in header filter chips. 4. Check if you are applying both parameter and runtimeFilters - If both are present, confirm they target the expected fields and don’t conflict in UI behavior. ### Minimal embed pattern to keep consistent filter scoping ```javascript import { init, AuthType, LiveboardEmbed, RuntimeFilterOp } from "@thoughtspot/visual-embed-sdk"; init({ thoughtSpotHost: "https://", authType: AuthType.None, }); const embed = new LiveboardEmbed("#ts-embed", { liveboardId: "", runtimeFilters: [ { columnName: "Warehouse", operator: RuntimeFilterOp.EQ,
values: ["London Depot"], }, ], // If you use compact header, keep behavior explicit: // isLiveboardCompactHeaderEnabled: true, // hideIrrelevantChipsInLiveboardTabs: true, }); embed.render(); ``` ### Practical workaround (if picker values remain broad) If your requirement is strict UX (users must only pick departments valid for selected warehouse), a reliable approach is: - Keep warehouse as enforced runtime filter from host app. - Replace ThoughtSpot chip for department with your app-controlled selector. - Re-render/update embed with runtimeFilters for both warehouse + department. That avoids dependency on picker-list scoping behavior. If you want, I can help you build a step-by-step debug checklist against your exact embed config (init + LiveboardEmbed options + how you pass parameter/runtimeFilters) and pinpoint the mismatch quickly.
t
So we should be using runtime filter instead of runtime parameters? We don't want the users to be able to change the warehouse themselves, only the department
r
Hi @Tim Jacobs you can try using the run time filters for your use case, here is the doc : https://developers.thoughtspot.com/docs/runtime-filters
t
I tried marking as solution but it errored. Switching to runtime filters worked, but not sure if our parameter implementation was flawed in someway or if it's just not best practice anymore. Thank you