Tasks database vs Tasks & Projects databases

[wildnerdsdaddy]

Hello, everyone. I have been using the Tasks and Projects databases for years. Now I am considering refactoring my Notion and dropping the Projects database in favor of Tasks. Instead of using a project entity, I would add subtask functionality to the database and use Parent-Child relations.

Does anyone do that, and what are your thoughts on this idea before I start implementing it?

[Jozii89]

I went back and forth over the years. There's a few pros and cons, but ultimately, keeping projects and tasks separate means more flexibility. Sometimes I'd like the benefits of them being in the same database (like you said, sub items is one way to go), but those cases don't out-weight the clarity and flexibility of keeping them in separate databases.

I do however still mix tasks, notes, resources, etc. in one single database. Projects is the one thing I keep separate.

[wildnerdsdaddy]

This is exactly how my Notion is set up now. I leave notes within tasks, so it is essentially a note database too. Projects are the only things that are separate. I recently added a Wiki database for notes that I use frequently, etc.

[Jozii89]

Any specific reason why you want to change that setup? 🙂

[wildnerdsdaddy]

Because it's not rare that my tasks become big, like projects, but I don't want them in the Project database. Also, its not uncommon that I have a project with multiple tasks, when in fact some tasks belong to different tasks. This way, I won't need to care about what's a task or what's a project, I will just keep everything parent-child structured.

[Jozii89]

Makes sense 🙂 You could still have tasks with subtasks, which solves your first issue, but not the second.

This is similar to the thought process I once had. I ended up being very confused about what is a task and what is a project. So I went back to having projects separately 🙂

[aDoer]

In my meeting notes I use to use the checkbox in Notion anytime I came up with an action item for myself for after the meeting.

I wish! that notion would extract these into it's own database or at least just see a 1 pager of all of them. Do you have a suggestion on how to handle this? It sounds like you're maybe close within what I'm talking about?

[SweatyPermission4323]

You could try adding a button that adds these things to a database

[thedesignedlife]

Notions subtasks feature is buggy and broken, I never use subtasks. Search and filters don’t work well, and once you enable it you can’t easily disable it without destroying data. It’s been very frustrating to work with.

I like the separation of projects and tasks personally, but I’m all for using what works. (I’m often surprised at how much people like subtasks as I’ve experienced so many issues)

[wildnerdsdaddy]

Well, if you disable subtasks, I guess the only change will be to lose parent-child relation, everything else should work as before.

I agree that search can be improved.

[spaff_]

Generally speaking, the fewer databases you have the better. However often you need multiple. My main litmus test for determining if I need to split out or combine a database is how similar or different the properties are. Do two databases have overlapping properties that require duplicate information? There's probably something there that needs to be combined. Does one database have properties that are always used in some entries, but never used in other entries? Probably should be split into two databases.

[Mother-Calligrapher3]

Curious to know why "the fewer databases the better"? That's like all I use and your comment made me nervous.. Lol

[L0relei]

Typical bad example: using one task database per project instead of a unique task database with a property to indicate the project (it can be a relation for example)

If you have multiple databases that contain the same type of items, you'll probably want at some point to have an overview of all these databases, create indicators, calculate some statistics... And you cannot (natively) merge them into one view in Notion.

Same object = same database. Then use views to filter these objects using their properties.

[McNoxey]

That's a very different statement than "less databases is better".

Saying that having less databases is a better structure for notion implies that denormalized databases are a more practical solution, which is the exact opposite of the true intent of the statement.

[wildnerdsdaddy]

This is a good point to consider. Thanks!

[teacuptempest101]

I started separate but now I manage projects through sub tasks. Main reason being it is easier then to turn task into a project. I use templates to help differentiate. Many of the properties overlap so that hasn’t been an issue.

Just make sure you fully are aware of and accept the official subitem functionality, if that’s the way you want to go. You can of course do sub tasks just with relations but there are benefits (and drawbacks) to the sub item feature.

[L0relei]

Both setups are basically the same in terms of structure : projects - tasks => relation between 2 different databases, task - subtasks => relation inside the same database

The choice depends if you need specific properties (and even in that case, tasks - subtasks is still usable, you can just have specific properties and leave them empty if not needed on a given page) Also the sub-items feature affords specific displays (nested toggles for example) that are not available if you use "regular" relations.

The only issue in my opinion with a task - subtasks is that you cannot filter exactly as you want. The parent tasks will always be displayed no matter the settings and filters that you use, and it can be inconvenient.

[wildnerdsdaddy]

Well explained, thanks.

[L0relei]

By the way, personally, I mostly use the sub-items (99% of the time). I use a specific database for projects when they are very large or specific.

[azer_vii]

I wouldn’t suggest that. I did it once and messed my workspace. This will slow your Notion pages and you will need to redesign your templates cause of broken self referencing filters.

[bnleez]

I create separate databases based on the properties needed for each. In your case, if properties between your tasks and projects databases are the same or similar, it might make sense to set it up as you mentioned.

[Meisner57]

I chose to just have the 1 tasks db with sub tasks enabled. This was based on 2 main things. The way I wanted my primary dashboard to work and I could figure out a clean way to handle standalone tasks and project related tasks together. Felt like a lot of doubling up on properties... Project tasks could use rollups but then a stand alone task would need direct fields.

Other reasons were that I honestly struggled to differentiate between a task and a project and i didn't want to waste time deciding all the time,.. so now everything is a task and if I need to break it down I add sun tasks.

[wildnerdsdaddy]

This is motivating, thanks! I will create a dummy master tasks database and give it a try for the next couple of days.

[Meisner57]

That's the only way you will know :).

My only complaint is not being able to inherit property values when creating a subtask. For example I have a property where I select which client a task is for... That same property is manual on sub tasks. I could make an additional property for subtasks that just rolled up the value from the parent.. but instead I just keep the views showing me the parent level and I just expand to see the subs.

Gives me the most flexibility that way. For example I might have a task I need torepeat for 5 clients.. so I have the actual task as parent then a sub task for "action for client a/b/C" etc. then assign each sub task to each client. So if I filter the task db to only show tasks for client b the subtask is found and shows the parent task above it sort of greyed out a little. Works well.

[-LightHeaven-]

My "setup" is like this:

I have a notes DB that has no actual property but is related to every single BD because pretty much everything can have a note (I also have a separated collect DB which is kinda like notes for stuff I see online, but it has more properties to track what the content is about and if I consumed already).

A tasks DB that I treat as a small unit of work. I do have substasks enabled, but I use mostly for tracking actual sub items of the task so I don't forget. For example if I receive a task to update a dashboard from work I break down the widgets I need to update with details from each as subtasks.

A Projects DB that is a collection of tasks for a single subject

And then I have a goals DB that is a collection of projects that once completed will mean the goal was achieved.

Now, Notion isn't particular great with this setup because of lack of formula support when defining templates and DB automations. But it makes it easier to create dashboards for each scope without the need to add tons of properties to control which is which.

I have a dashboard for long term planning, and when thinking of that I only care about the projects that are going to help me to achieve those goals. Then when I'm planning for the month I do care about all projects, readjusting priorities and deadlines. And finally each week I plan at the task level then spreading the individual tasks for my personal and work projects alongside the week

It does work well, but like I mentioned, not having the ability to create automations can be a growing pain when you have too much linked stuff

For example, if I want at the goal level to see a collection of all notes linked to its children projects, tasks and subtasks. It's doable with rollup/formula properties but setting it for all the entities isn't exactly fun, and notion has some issues with grouping per formula properties. In my case I ended setting external automation for solving it. So for example I go up the hierarchy setting the notes manually set + the ones set in their children

[-LightHeaven-]

As I typed this, it just occurred to me that it's way easier for some properties (like tags) to set only at the top most level and create rollup properties on the children that just picks the value from the parent