Hey there 👋,
Today we’re launching nested search in Workflowy, a powerful feature that dramatically expands how you can use searches. It can let you do things like find only your most important tasks, or find all the questions that arose in meetings with a particular client.
Nested search works by letting you search for stuff inside other stuff, by adding a “>” between them. For example, “#project > is:task” will find you all the tasks inside all your projects. You can refine that as “#important #project > is:task” which further narrows the search to only show #important projects.
Here are some more in depth examples:
Example 1: Finding open questions from client meetings
Imagine you’re working with multiple clients and each of their projects has a “Meetings” section where you keep track of your discussions with your team.
Each client bullet has multiple sections for tasks, documents and meetings.

Whenever an important question comes up you tag it with “#question“. However, you also use the same tag in other parts of your projects. So say you wanted to only see the questions that have come up in meetings, how would you do that?
Before nested searches, there would not have been an easy way to do this. But now you can narrow down your search and specify that the ancestor item should match “meetings” as well.
Let’s first search for the ancestor by searching for “meetings“. This should show all items that match that.

Now we’ll turn this into a nested search using the new “>” search operator. So a search of “meetings > #question” lets us tell Workflowy that we want to see “#question” items, that are descendants of “meeting” items. In other words, show us all the “#question” items that are nested under a “meeting” item.

Perfect, so now we’re only seeing the items that have a “#question” tag that are also nested under a “meetings” item.
Let’s look at a second example.
Example 2: Finding next tasks from your most important projects
Say you’re working with other folks, running a web services agency. Let’s also say you use “@” to assign tasks to other team members.

Say you wanted to look at all of Sam’s projects. You would of course search for “@sam“.

As you can see, Sam has a bunch of tasks assigned to different projects.
Now let’s say we only want to see their SEO tasks. We’ll do this using a nested search with the new “>” operator and search for “SEO > @sam“.
This will ask Workflowy to only show us @sam items that are also descendants of an SEO item. In other words, show us all the “@sam” items that are nested under an “SEO” item.

Great. But let’s say we only want to see Sam’s high priority projects.
Again, we’ll use another nested search to specify that we only want to see items where the ancestor has a “#high” tag.
And we’ll do that with the following search “#high > SEO > @sam“. This is basically saying, show us all the @sam items that are nested under an “SEO” item, that are nested under a “#high” item.

Nice. And now we only see @sam‘s tasks that are SEO activities that are part of #high priority projects.
Hopefully, these examples give you an idea of how using nested searches with > gives you even more control over your searches and allows you to view your information in more useful ways, no matter where it’s located.
Please note that ancestors do not need to be immediate parents of the item. They can be many many levels “above” the item you’re looking for. As long as they’re an ancestor item at some point in the nesting, the search will find them. This is one of the reasons nested searches are so powerful.
Changes we made based on your feedback 🫶
We would also like to thank everyone who provided feedback while the feature was in labs. It’s thanks to you that we are able to improve and polish the feature for the benefit of all Workflowy users. Here’s some specific feedback regarding nested searches we addressed and the users that brought it up.
- Ksenia via Slack group
“Searches should exclude results where a single item matches multiple search terms “
We’ve made it so nested searches are more narrow and only show results where the relationship among the search terms has to be that of descendants or ancestors.
- Sandro via Blog
“Searches should work in the jump-to menu“
You can now use nested searches to navigate around Workflowy using the jump-to menu.
- Aukirk via Blog
“Searches should work with the ‘Move to’ command“
You can now also use nested searches with the “Move to” command to move items with greater precision.
- workflower via Blog
“It would be great if negations also worked with nested searches“
Negations now work with nested searches. Adding a minus sign to a search term means the nested search will exclude that item at that level of nesting.
Keep that feedback coming on this feature and any other you think we should know about.
Until the next one, peace out.
good job : )
Very useful. Thanks for adding this!
I love thiiiiiiiis
I’ve never seen this feature in any other product. I am now tempted to use Workflowy for even more of my note-taking. The only thing stopping me is sadly not enough rich text support for notes like bullets and strikethroughs. I’d love Workflowy notes to be like Evernote in that they support standard rich text editing.
Workflowy doesn’t support bullets? That’s a new one. 😂
This feature is a really big deal and I think everyone involved in making it happen.
There is an odd behavior which I can see works from a logical/code point of view but I’m unsure I like or could be improved. If I use the search string
I get a lot of results that are completed. Except on close inspection I have completed the root of a node (the title of a task) but not the subordinate nodes. This is because my workflow is to simply ‘complete’ the parent node of a task when I’m done.
The result is that the nested search brings up results where I’ve completed the tasks because the hit is on an non-completed subordinate of the completed title.
So while I can see the search is doing what it is told, it goes against what I intend. So I guess my question about nested search is “should -is:complete see past parent nodes that are completed?”.
I suspect I just need to change behavior and complete entire branches somehow?
Hey Ian, so when the negation operator is combined with nested searches, the results can sometimes be a little unexpected but on closer inspection they match the search query.
Since nested searches don’t care about the ‘depth’ of the ancestor – as long as somewhere along the branch there’s a positive hit for the search query, it’ll count as a match. So that’s what appears to be happening in your example.
A possible solution would be to have some way to specify the depth of the ancestor or a way to specify that the nested search should return results only from parent nodes and not all ancestors.
I love the nested searching but am stuck on the “negation” flavor. I’ve shared a list to demonstrate. Thanks in advance for any clarity!
Hey Brad, I tried your example and the negation is working for me, unless I’m missing something. Could you explain what the expected output for the negation case is? The screenshot is what I get for the “-#med > is:todo” case.
what on earth?? I’m it works but i’m still getting this for (what looks like) the same query. (I’ve logged in/out of the web app, force reloaded, etc.)
(I’m *glad* it works”)
That’s really odd, what browser are you using and what version? Also, you’re not using beta.workflowy.com right?
I can replicate the bug/issue in Chrome 119.0.6045.123 and Safari 17.0. I’m not using the beta.
¯\_(ツ)_/¯
That’s very strange, let me pass this on to our support team and see if they can’t figure out what’s going on.
(No hurry—just wanted to see if there are any updates. I’m still unable to get -#someTag > content to work)
[…] […]
Rodolfo !!! la nueva búsqueda me cae como un anillo al dedo. Muy buen lanzamiento. Ya me imagino creando un nuevo panel de control o dashboard por medio de enlaces resultantes del uso de nuevos criterios de búsqueda. Genial 👍
Carlos, me alegra saber que la función te es útil 👍 Es de esas cosas que parecen sencillas pero resultan ser muy útiles.