Easier ways to work with Subtasks that are within the same table, Grouping

There are a couple things I would be cautious of when trying out these strategies. Coda is a very flexible product that lets you do nearly anything you can dream up, but this also brings with it a little bit of responsibility in finding the right schema to use. The other side of this is removing all freedom and only allowing what is absolutely safe to use…which isn’t any fun. So we work hard to find the right balance of limiting a few things while also allowing the freedom to push Coda to new heights.

The first word of caution is that you can create circular references, This is where a formula tries to run that affects a row that is linked to another row that causes the first row to jump back into a calculation. This happens often with many-to-many workarounds and these can crash your doc. An example here would be having a Projects table and a People table and wanting to add people to the projects and projects to the people. It’s best to consider one direction of association in these cases.

The second word of caution is that you can drastically increase the size of your doc and performance can take a big hit. Here is a very simple example of a Projects table and a Tasks table. I only have one lookup column that allows only one option for each row. You can see when you hover over the previous rows reference in the column that all information from that row is included in the current row too. You’ve pulled it in with the lookup. You only have to do this twice for these to chain together, and at 3 times, you’ve quadrupled the data for a single row. A contains everything in B, which contains everything in C, which contains everything in D. This isn’t literally written data over and over, but it can operate as if that’s the case when formulas are involved.

You can see how much data fans out from the last row alone of this very simple table…which then will fan out again to include the Projects table row. So think about how complicated this gets if you have a couple dozen columns and hundreds of rows.

Be creative and give things a try for sure, but also check your schema for things that might add up over time. A well engineered doc doesn’t mean it has every feature you can think of, it means that it’s found a fine balance between efficiency and productivity.

For the reference to folding, this was a canvas feature that we released already. We may find more table tricks in the future, but they aren’t currently on the map.

Further Reading

Here are a couple great help articles that give some insight on how to better optimize your docs and formulas…

I’m always happy to help, but I also don’t want to let anyone build themselves into a corner, so I do look for schemas that will give you a long running and happy doc in the end!