Hi
I’m organizing our workflow by projects. Each project has its own page with a dedicated table to track tasks for everyone involved. However, our developers often work on multiple projects simultaneously. I’m looking for a way to achieve the following:
For Developers: How can I create a personalized view where each developer can see only the tasks assigned to them across all different projects in one place?
For Project Managers (PM): How can I build an overview dashboard that allows a PM to see exactly which tasks each developer is working on across all active projects?
Since a Master Table is not an option due to speed concerns so what is the best architectural approach for this in Coda? Is there a way to sync multiple independent tables into one master dashboard?
Because by FAR the best architecture in this scenario is a single table with different views filtered as needed.
As my project manager used to say - given enough time, and enough budget, we can build anything….
If you have different tables, what exactly you want to see in your “dashboard” is going to be very important. Say, you want to see a summary across all projects of the time a developer recorded. You will need to write a formula, with a SwitchIf to read each table, and summarise the information.
When you add a new project, you will need to go and revisit all of your formulas, and add the new table for the new project to that.
If everything is in a single table with proper filtering, all you need to do is use the new project in the project column. That’s it.
It is strongly discouraged to create multiple tables to store similar data.
Thanks for the suggestion. We did consider using a single master table with filtered views, but in our case there are a few practical constraints that make that architecture difficult.
First, our organization has multiple PMs, and each PM manages projects slightly differently. While we start with the same base table structure, in reality each PM has different workflow needs, custom columns, and project-specific tracking requirements. Because of that, even though the tables look similar at the beginning, they gradually diverge as the project evolves.
Second, we actually tested the single master table approach in practice. In one test scenario we had 6 developers, 2 QA, 3 PMs, 4 UA, and 1 intern working on the same master table. The experience was quite poor:
Table responsiveness was slow. When users updated data, the changes did not appear immediately. This caused confusion because people weren’t sure whether they should wait for the update or repeat the action.
Operational friction increased. With many people interacting with the same large table simultaneously, the UI became noticeably slower.
Project rules are not uniform. Different projects have different processes and requirements, so applying a single standardized structure or rule set across all projects is not realistic.
Because of these factors, we intentionally separated projects into independent tables. This gives each PM flexibility to adapt the structure to the needs of their project without affecting others.
What we are trying to solve now is simply the developer visibility problem — allowing developers to see all tasks assigned to them across projects in a single place, without forcing all projects into the same operational structure.
So the goal isn’t to replace project tables with a master table, but rather to create a lightweight aggregated dashboard that can read from multiple independent project tables.
