Add support for customisable TODO keywords

Interesting that this is not prioritized more, considering that built-in task management tends to be mentioned as one of the top advantages logseq has over Obsidian. Why not focus on the strongest parts?

As a side note how well does this Trello board corresponds with dev plans? Not just this, but most of top-voted suggestions from this board are not included, not even in long term. Are these in even more distantier future or is that board incomplete?


I’ve been moving back and forward between Logseq and Obsidian, and one thing really stops me from committing to Logseq,… this feature request.

What’s fundamental to both is that my data is locally stored and I can work with no internet connection, and that data is in a format I can utilise elsewhere. Task Management is a key activity for knowledge workers, and for me it’s crucial.

Earlier in this very thread, here, Aryan, shares a Logseq plugin that comes some of the distance, but doesn’t fully close this loop for me. It may be enough for others, but I suspect there is a substantial number of others here that really want their own workflows, in their phraseology, to be easily implemented in Logseq.

My feeling is that this should be in the product out of the box. Much the same as every other person wanting their feature native to the product :wink: But I recognise that my priorities and needs may not be the same as those who get to control what is given time and effort.

All the knowledge workers I know have more than one distinct workflow. The two workflows I described at the outset of this thread, are (almost) still the same.

(setq org-todo-keywords
        (sequence "REPORT" "BUG" "KNOWNCAUSE" "|" "NOTFIXING" "FIXED")))

Using block properties kinda works, and if there was a plugin (perhaps there is?) that would allow me to manage tasks using block properties, then that might remove the final amount of friction here for me.

It could be a plugin that:

  • uses a block property status (or similar)
  • we’d need someplace to specify the workflow sequences
  • the order of statuses in each sequence
  • for each workflow, which statuses are ‘open’ statuses, which are ‘closed’ statuses
  • set a keyboard shortcut that would cycle the statuses for the current task, through the values in the sequence for the workflow in use (happy to keep statuses globally unique as this keeps it easier for humans to both know where in a workflow a thing is, and which workflow it is in)
  • ideally a shift-<keyboard_shortcut>` would cycle in statuses in reverse order (or separately definable)
  • bonus would be to track total time in each status (I’ve not need to keep an audit of when it switched back and forth

Thusly, if there isn’t going to be any communication from the developers, either via this thread, the roadmap, or via git issues, then are there any plugin developers interested in discussing this further?

Specifically, I’m curious to know how much time/effort you’d feel is involved in achieving the above.


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.


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.


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! :rocket:


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:

next:: #task/doing

Possible UI implementation:


  1. You can open #parent/child page to have an overview in Linked References for example of #task/todo.
  2. You can open #parent page for the same overview of all #task, #bug etc.
  3. You can further specify by adding other levels like #bug/closed/wontfix that still count as #bug/closed
  4. The three points above but in queries, for example (and [[project]] [[task/todo]])

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%;


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 :rofl:

Tags are super powerful, can replace basically anything.


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


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.


@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


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.