Hi Jason-
Thanks for the feedback, we agree that it would be very useful to have filters on both types of tables. It is something we would like to add, but it is not likely to be right away unfortunately.
Is your variable sourced from a SQL connector function? If so, a potential workaround could be implementing your query with some filter options as well (the only downside here is you would need to re-execute the query to search vs. the dynamic filtering that embedded tables have). You should only need one query and just use a WHERE and SIMILAR TO SQL statement so it works with or with out the filter!
@Grant Sorry I didn’t see this earlier. I thought this would send an email, but that’s another topic…
The variable is HTTP (REST), not SQL. But I get your idea, that I could use inputs and parameters.
Exactly. A relatively small amount of data can still be huge list to scroll through. So active filtering would be great.
To do this with constant API calls, it can take a few seconds for the round trip, which adds up if you aren’t a robot who goes directly to the data it needs, but rather you poke around a bit till you get the right job number or whatever.
Hey all, I just wondered if there was any progress on this suggestion. @pete@Grant
I’ll admit I never visit this forum anymore, but @MikeRousch and I have still been quite busy implementing Tulip here quite extensively, and we ran into this issue again, where we can’t live-filter a table that is a variable.
Hi @JasonMcD- You have very good timing because we are looking at this right now! There is a good chance this is released by the early summer so keep an eye out -Pete-