This x1000. It seems so obvious. I want to be able to add sub items that describe my checklist action item, but aren’t necessarily TODO items themselves!
2 Likes
What do you mean? I’m not sure if you’re suggesting in favor or against this feature request 
Hi @Matt_Myers, I agree the need is obvious, but the implemention is not, at least from our consideration.
I take it that you want checklist to affect only one level of children (direct children) and nothing more?
This sounds the simplest and handiest solution:
Looking forward to having more freedom with checklists!
Just realized the feature “Force item to not have checkbox” is in Trello roadmap.
All the best with the development!
1 Like
We look forward to it as well! And thanks for the kind words.
Just want to chime in and say I really want this feature as well, e.g. I want to be able to have a parent node that is a checklist, but it has child nodes that are NOT a checklist.
Personally I think making this an option in settings is just adding yet another option to an already bloated option list. I think really the default should just be that when a parent node is made into a checklist, it does not automatically make everything below it a checklist. Or, it does make everything below it a checklist, but you have the ability to “un-checklist” any of the below items.
People who want everything below it to be a checklist would still be able to do it, they just have to do it manually. Is that really a big deal? They can just select-all and toggle it to checklist, not hard.
And, I would hazard a guess that people who want the feature as it currently is are in the minority anyway, that most people would rather have control over whether a child node is checklist or not? Sometimes you can’t please everyone. If the people who want the feature as-is were in the majority and I am one of the weird ones that wants control over whether a child is a checklist or not then I would happily accept not having that feature and working around it. But I would bet that is not the case, I bet most people want control and thus those that want it as-is should just have to do it manually.
2 Likes
This feature is much needed.
I have some repeated tasks that have some subtasks. I set the due date and repetition on the parent task, and not the subtasks (because repeated subtasks of repeated tasks don’t behave nicely).
I also have a search saved to find all tasks without a due date (is:checklist -has:date). But if I make the parent task a checklist, then all the subtasks become checklists too and show up in this search.
I could work around this with tags, but that seems a bit tedious when the obvious solution is the ability to not make children checklists just because the parent is a checklist.
My two cents: I would like it if it worked similarly to the way numbered lists work now. That is, I could set a node to contain a checklist, just like I can set a node to contain a numbered list. Children of the parent node are all checklist items. Children of the children are just regular nodes.
2 Likes
+1 for this, I often have an item which is a task and I want some sub-items that are not themselves tasks, just notes on the task to be done. To me the behaviour of automatically adding checkboxes to children and not allowing you to remove them goes against the design philosophy I’m used to with Dynalist which is to be unopinionated and allow the user to use a low-level feature set in a way that works for them.
1 Like
Same here.
It seems far more in line with Dynalist to let people decide for themselves what is and is not a checklist item.
Just started trying out Dynalist and this is the first negative thing I noticed.
I came to this forum to make this same exact suggestion, and looks like the developers are already working on it. Awesome.
Edit: actually looks like this was posted back in 2017… any plans to still implement this feature?
Hmm the unresponsiveness of the support/development team is certainly not inspiring confidence in me to make the switch from Workflowy. Guess I’m sticking with Workflowy Pro for now…
Sorry about the late reply!
We did plan to fix this since 2017, but it’s a pretty complicated issue with added migration complexity as well. Recently we realized there’s a better solution to this problem, and this time I think we’re closer to making this possible than ever. Stay tuned!
Hi @Erica
Any news on that? I would also love to see an option to having checkboxes only on the same level of indentation.
Thanks, Eberhard
Hopefully soon, although I don’t think the new behavior would be to have it work on the same level of indentation.
Related poll: Desired behavior when adding a checkbox
Thank for more flexibility with checkboxes. However it has a big drawback. I collect tasks and ideas in different lists without any checkbox. Then there is a list for today where checkbox for childrens was activated. This was very nice. When I moved an item to the todo list it automatically became a task with checkbox.
With the new implementation i need to do all the checkbox stuff manually. 
Can we get back a way of explicit listes with checkboxes, where all children created or moved into get a checkbox attached? Can there be an explicit non-checkbox-lists where the checkbox is automatically removed from the checkbox?
Unfortunately this seems to need a new property for lists in current implementation, dont it?
I don’t think so, unfortunately. Having both checklist and checkbox is too confusing in the app.
The workaround would be to do a “add checkbox to children” on the parent from time to time, or add the checkbox before sending it off.
Again I really welcome the possibility to change the checkbox per item by will.
But I tried it out for a while now. Not having a checkbox-list is really annoying for me. Moving items from my Backlog to the TodoList, i need to check every item indivudally now. The workaround to use the “add checkbox to children” time by time is very unconvinient.
I wonder, If I am the only, who is uncomfortable with the changed behaviour?
But I have an idea, that could work to introduce checklists again while keeping the individual possibilities. I will create a new feature request.