Hi, I would like to display action item from different tables (coming from different applications) in single Interactive table so Operator will have all assign task for him in one place. Columns which I would like to use are common across all tables. Anyone tried something like this?
Hey @Kris, thanks for the question—it’s a really good one!
This depends a little on how you structure your solutions
If you have data being generated by several different applications but being stored in a single table, you can absolutely use that single table as the data source for assigning tasks to an operator. You can use filters on the interactive table to align the logged in user property with the assigned user in the table.
When I read your question, however, I’m drawn to the phrase “columns… are common across all tables”. Are you also talking about surfacing data that exists in several different tables into a single interactive table UI in an application? If that’s the case, I’m happy to change this to a feature request as that’s not something we currently cover but it’s an interesting suggestion.
Let me know, because if it’s option 2 (data is spread across many tables), there might be some solution architecture refactoring we could recommend to get you where you want to be.
Hi John, thank you for prompt answer.
This is second case, we have different tables were some of Table Record Fields (Columns) are common for all I would like to combine in one. I was thinking to leverage connectors to load data in temporary table and then based on trigger update data in primary tables and reload temporary one. But maybe you have other suggestion?
Thanks @Kris for the response. In general, we advise against having secondary data tables unless absolutely necessary—usually there’s a much simpler solution hiding in plain sight. The big reason here is that solutions that rely on secondary tables can introduce a lot of complexity that can make it difficult to adapt and scale apps/solutions. I want to include a couple of resources here to share some context, because I think it’s helpful to understand why we make these suggestions:
-
Composable vs. Monolithic architectures - good for understanding the general archectural principle at work here
-
Tulip solution credo - a breakdown of the different characteristics of apps and why they matter
-
Tulip common data model and Tulip’s data model overview for a deeper dive into Artifact and Process table types and why we recommend against secondary tables.
If you could hare a little more about how your tables are structured I can pull in some additional teammates here to see if there isn’t a way to this data into a format that works for you
Hi @John
I have a similar situation.
I have a table with “cost centers” (ID Number, Resposible, Department Name…) and one with “Reasons for interference” (ID Number, Short description, Long description, date of introduction…).
For both there are several usages, one is “disturbance time recording”. Therefore is another Table with booking numbers, that are related to a combination of cost center id and reason id.
I have a table with all combinations of cost center and reasons to map the resulting booking number.
And I have a table with disturbance time recordings to book.
If I would use the Cost Center information redundant in all of these Tables, and the responsible changes, I would have to replace it for all affected booking numbers, and for all affected disturbance time recordings to book… hundreds of entries!
If I would also completely avoid the cost center and the reason tables, I would also forego the availability for other apps (e.g. to select a valid cost center by department name).
Isn’t this exactly a composable approach to have those data separated and available for each use case? And to introduce small separately maintainable pieces of functionality gradually?
@thorsten.langner, thanks for sharing the context and use-case here!
What you’ve described is a accurate and, to your point, this is where discussions of solution design get tricky. There are plenty of situations where we see folks use techniques (secondary tables and parameterization come to mind) that aren’t technically best practices, but do make a ton of sense for their situation and use case. The key is that, as you said, they’re always solutions that are arrived at organically and incrementally during the solution design process. What we try to advise against is basing a solution design on master data managed in tables, complex techniques like parameterization, and basing app functionality on interactions with secondary tables. There’s nothing inherently wrong with any of these techniques, but they can veer into monolith territory really quickly.
Let me end with a question: would your use-case described above be solved with table join functionality? It sounds like in both of this and @Kris’s case, more relationality between tables might help.
Thanks for your thoughts about that.
I would go even further. I would like to join different sources (http-, sql-connector and tulip tables)
This would reduce the redundant cost center table (typical master data from erp) by just getting the information from its original source.
However, I was a bit fast with my input here, since the original post seems to ask for something like union and not join.
To simply display additional information from another table (join like) you could also use the link, however this is very limited…
Currently we have 3 application = 3 different tables:
- Action items from identified and categorized as defects assigned to owners,
- Changeover Management activities,
- Cleaning tasks.
More application are under development and because how data is loaded to tables and detailed information we need we keep them as separate tables.
What I’m truing to achieve is to build application containing information assigned for particular person so they will have full overview of tasks + in near future we will have more apps. So in a nut shell my goal is to build “task planner” combining task form different tables.
I don’t want to use several interactive tables as this won’t be best way to present data.
If you could suggest something different than secondary table happy to consider other options.
Hi @Kris sorry for the delay here. This use-case for secondary tables makes sense to me and given the desired outcome seems like a good work around, thanks for sharing.
I also think this is an interesting use-case for our product team to be thinking about so I’m going to share it back with them. The idea of either joining tables of surfacing data from multiple tables into one interface seems super useful.