List View hierarchy feels backwards

Hey @BobH! 

This is correct behavior for how the list view is implemented.
For this type of implementation, I would recommend a structure of two tables: Projects and Tasks.

From there, you would leverage a linked record field to define the dependencies between different tasks.
I recommend this for two reasons.

Firstly, this would resolve the potential confusion that might come from having two tables and would allow you to keep a consolidated and more semantically friendly list view. This is particularly true since list views have native support for displaying parent/child dependencies. It's worth noting that child-to-parent defined relationships are not displayed. The dependency must be a parent-to-child relationship to be properly displayed.

Secondly, this is in line with a cleaner schema and overall database design best practices.
When thinking about tables in a database, each table should hold records for a specific type of thing.
If two tables both store records for the same type of thing (in this case, tasks), then you set yourself up with a considerable amount of technical debt before you even start thinking about your fields, automations, and views. It's easy to say that it's no big deal and write it off as something that can't do much harm, but in my time working in Airtable and with the data structures of many teams and organizations, I can attest that taking the approach of separate tables for the same entity type has never turned out to be a good idea in the mid-long term.

If you are concerned about your users and their workflow experience, then I would recommend that you don't share the base with them at all. Instead, craft an Interface that will fit their needs and eliminate the need for them to manage views, worry about which table is the correct one, etc.

Hi Thanks for looking at this Ben,

I've tried limiting it to two tables (Projects) and (Tasks) and used a linked record field to link to Subtasks. I'm now having a problem showing the 3 layers of information in the list view.

Each time I try to make a List view, it gives me an info panel saying, "Each level corresponds to a table in your base". I can add subtasks by using "Enable nested records for this table" under the Tasks level, but it's not great - there's no way to add new Subtasks in the List view.

Curious. Could you provide any screenshots of what you're seeing and describe what you'd like it to be instead?
I've always found the list view's handling of subtask handling quite intuitive (albeit currently limited).

Hi Ben, This is the sort of thing I'm looking to do. 

Thanks -Bob

Hi @BobH,

To get the behavior shown in @Ben_Young1 's demo video - you'll want to set up subtasks in the same table as your tasks, and use the "Enable nested records for this table" setting like you discovered earlier.

You mentioned "there's no way to add new Subtasks in the List view.".  You're right that there's not a "Add subtask" button in the view like there is for creating new Projects or Tasks. However here are two ways to add subtasks:

1. First create the subtask as a task, and then use drag-and-drop to move it underneath the task you want

2. Add the "Subtasks" linked record column in the task table as a visible field in your list. Then you can use the linked record editor dropdown to select the correct subtasks.

There are a few improvements we're thinking about to make this even easier in the future, but I hope this helped!

It IS broken...you have to design your bases backward, and it's the furthest thing from initiative. You are forced to select a "parent" table from the table you want to view the listed data in, and for me, its NEVER how I want to use this feature. 

For example, I have leads. And I have activity for said leads. I want a simple list ON the leads table that shows leads and their activity. HOWEVER, I am forced to make activity a "parent" or level above leads on the leads table, which absolutely makes zero sense.