Screenshot of how I’d see block properties utilised
I love Logseq TODOs but they could be better. There are two nomenclatures for the same thing: TODO/DOING/DONE and LATER/NOW/DONE. Thus the app supports a single workflow. Why not allow multiple workflows (state machines) to be defined within the config.edn?
Kanban/Trello boards (e.g. workflows) can be almost anything you can imagine. Logseq already supports workflows, it’s just that it only supports a single basic one. Why not allow customizable workflows? Folks are wanting to tweak the basic TODO workflow anyway.
{
:workflows: [
{:name :TASK :incomplete [:TODO, :DOING] :complete [:DONE] :cancel [:CANCELED]}
{:name :ARTICLE :incomplete [:IDEA, :DRAFTING, :EDITING, :PROOFING, :DEFERED] :complete [:PUBLISHED] :cancel [:DISCARDED]}
]
}
If the same term is used in multiple workflows no matter. When adding a new block using a term it will automatically assume the first workflow which uses the term. Then a keystroke allows the user to visually cycle through the workflows sharing the term to disambiguate. In that case, a hidden piece of metadata (like the collapsed block state) can track the select workflow. Hopefully shrewd users will avoid reusing terms, but it may be unavoidable at times. (All terms are stored in the marker slot of block objects.)
The incomplete and complete states allow the task to be checked off in normal fashion. It could make sense to have only a single complete state but I don’t think it would be bad to be able to cycle between different possible end states. And having the cancel category is useful for showing an aborted workflow, just as Logseq already renders CANCELED tasks differently from completed ones.
While, obviously in a state machine it is possible to define valid transitions, I’m not going there. I think that cycling to the next desired state is good enough. And keystrokes (something?) could provide a means of jumping to the complete and cancel categories.
The benefit of having custom workflows is it solves the Kanban primitive problem. There are currently Kanban plugins but they are grafted into pages. Having workflows become the primitive would allow one to toggle the current screen between outline and board views much in the same way that Microsoft Planner and ClickUp and countless other tools do. And with Logseq as frequently used for GTD as it is for PKM, it’s not a far reach to say “it belongs.”
Making this configurable means your average user might never upgrade from ordinary to-dos into varied workflows. Everything would work exactly as it already does for such users.
5 Likes
Just resurfacing this feature request as we approach 200 votes. Unsure what the level of effort is on this, but it seems like a heavily-sought-after feature (to allow custom workflows).
Native support (as opposed to plugin) hugely benefits mobile users as well.
3 Likes
Hello everyone,
I wanted to share an exciting update with you all. Your feedback and discussions on customizable workflow state markers have been incredibly insightful, and I’m thrilled to announce that I’m now in the early stages of designing this feature!
As we continue to build the database version of Logseq, we believe it’s the perfect opportunity to start work on this much-requested feature. Our aim is to create a more versatile and personalizable task management experience for all of you.
The feature will allow users to create, rename, and manage their task states, and also customize their appearance. It’s still in the design phase, but our goal is to provide a seamless, intuitive way to manage and customize your workflows directly in Logseq’s settings.
Your ideas, use cases, and opinions are invaluable in shaping this development, and I want to keep this conversation going. As I progress with the designs, I will be sharing updates and requesting your feedback to ensure we’re creating a feature that genuinely enhances your Logseq experience. This will probably most likely happen in the Discord #design channel as it’s my preferred medium for quick input.
Thank you for your continued support, patience, and most importantly, your input. Stay tuned for more updates on this feature soon! 
11 Likes
To be honest, I’d given up. But this is very good news to hear.
Please allow the Checkbox to also appear at the end of the TODO. Many forms and journals have checkboxes as a last column and many brains work like that when checking on paper.
If you are using only one checkbox in each block you can align them to the right with this CSS:
.form-checkbox, .form-radio {
float: right;
}
1 Like
, kinda works … it’s just a tad unaligned…
About the issue of custom TODO keywords, if it was for me I’d trash the current implementation for something based on tags and namespaces:
- the user creates tags like:
-
#task/todo,#task/doing,#task/done -
#bug/open,#bug/closed - etc
-
- namespaced tags like these have a little button next to them that change them by cycling between tags of the same namespace
If order is crucial, then introduce a special property that these tags would have to specify the order:
task/todo.md
next:: #task/doing
Possible UI implementation:
Advantages:
- You can open
#parent/childpage to have an overview in Linked References for example of#task/todo. - You can open
#parentpage for the same overview of all#task,#bugetc. - You can further specify by adding other levels like
#bug/closed/wontfixthat still count as#bug/closed - The three points above but in queries, for example
(and [[project]] [[task/todo]])
5 Likes
Then add the desired margin top like this:
.form-checkbox, .form-radio {
float: right;
margin-top: 5px;
}
1 Like
This worked for me:
.form-checkbox, .form-radio {
position: relative;
left: 100%;
}
thanks.
I 100% agree. I already do something similar because I have items that are “todo right now” (like a checklist) and items that are “todo far in future when a certain thing happens”, and I already organize those through…guess what! Tags 
Tags are super powerful, can replace basically anything.
2 Likes
great you are working on this, just a suggestion: maybe take in account an option to have localized TODO keywords, I mean the workflow may be fine but user just wants those special words to be in the same language as the rest of the app… this ideally would extend for other words like SCHEDULED or NOW etc. -as they don’t look too good when mixed I think-
edit: for instance in spanish it could be something like: PENDIENTE ENCURSO COMPLETADO… words are way longer though
4 Likes
I love this concept its great! all I would like to add is keyboard shortcuts are key as long as u can use the ctr+enter to cycle them and have the ability to set a default. Then if u have it so when your cycling u can type a slash and be sent one namespace level deeper. E.g. to give a task “development/bug/open” u can do ctr+enter type the start of “production” then select from keyboard then u can use ctr+enter to cycle between “development/bug”, “development/design” etc etc then type another slash and cycle todo, doing etc etc
Just a possible idea but would mean you can add any tag to any item in any tag namespace ALL without having to remove you hands from the keyboard. Defiantly after a while the common ones you use would become complete muscle memory.
2 Likes
@futurized what are the advantages of using properties for tasks workflow instead of tags as explained here?
Notice that hashtags can be inline, so we could have compact one-line tasks. Properties instead force bigger blocks. Personally I like my tasks to have only one line.
I would love properties to be able to be placed anywhere inside the block (just like tags) and Logseq logic to be able to differentiate and use them as properties in an auto-hiding properties section. So, for example, I would have this task:
- Buy the milk status::Task/TODO:: (- Buy the milk ::Task/TODO:: would mean the same thing and the status property name would be auto-infered due to the workflow definition somewhere in config.edn or in the namespace). The result would be - [ ] Buy the milk. One would not need to place the TODO text right after the bullet but Logseq would still place the Checkbox at the beginning of the block while having the status:: property in the properties section as well.
In the case of status: property one would not see the TODO because it will be transformed in a Checkbox by Logseq UI, but for other properties this would open up so many possibilities. For example:
- In this book, author:: Dale Carnegie:: speaks about... would be rendered as - In this book, Dale Carnegie speaks about.... I am not suggesting the tehnical way to differentiate the property from its value and the surrounding text but the above would leave visible on-screen the value, while “pulling” into the properties section the author:: Dale Carnegie property:: value string.
Some of these are maybe feature-request material but I wanted to express here as well my need to have properties inline as tags can currently be placed.
PS: While writing the body of the block, one would refer to the saved properties as variable to be able to reuse them throughout without re-typing them again:
- Another interestng point I find author:: making is that .. → - Another interestng point I find Dale Carnegie making is that ..
@FlorianF I have proposed a syntax for inline properties here sometime ago:
CC @futurized in case you are interested
2 Likes
Cool suggestion. But I would add the property as dynamic variable to the mix and also block editor suggestions based on block text or properties values.
2 Likes
Wondering if there has been any progress on this recently?
I have been doing something similar to @alex0 suggestion, but of course its all manual (rather than clicking to change state, I have retype the tag.)
One further suggestion is that this be added to a workflow template as a property. By example, if a template is “Prepare Taxes” it might have a workflow:: property of “0:TODO, 1:DOING, 2:DONE” wheres a template for “Paying Bills” might have a workflow:: property of “0:DUE, 2:PAID”
In the DB version: yes, but tasks are implemented with the new “properties templates” i.e. you add the hashtag #task and then appear properties where you set to-do, done, priority, schedule ecc and you can create your custom workflows.