Folders and index notes store answers that go stale. A saved search stores the question and re-runs it every time. How to pick the few worth keeping.
· Note-Taking Basics · 8 min read
Every note system eventually settles into a handful of recurring questions. What is still open on the client project? What did we decide about pricing? Which book notes have I not processed yet? What do I need to bring up with Dana on Thursday? You ask them every week, sometimes every day, and every time you rebuild the answer from scratch: type the search, add the tag filter, scroll, skim.
The usual response is to build structure so you don't have to ask. A folder for the client. An index note titled "Pricing decisions" with links to every relevant meeting. A reading-queue list you add to by hand. It works for a month or so, and then the structure starts to fall behind. A new meeting note never gets linked from the index, and a finished book stays on the queue. The structure turns into one more thing to maintain, and when you stop maintaining it you can no longer trust it. There is a simpler move: instead of saving the answer, save the question.
A folder, an index note, or a hand-curated list is a snapshot. It records which notes belonged to a topic at the moment you filed them, and it is only correct as long as you keep filing. Every new note is a small obligation: remember to put it in the right folder, remember to add it to the index. Miss the obligation once and the structure is quietly wrong, and you have no way of knowing which parts are wrong.
A saved search, also called a smart folder, a live query, or a dynamic view, records something different: the criterion for membership. "Notes tagged #acme." "Notes mentioning Dana." "Open tasks in notes tagged #launch." When you open it, it runs again against everything you have written, including the note you created ten minutes ago. Nobody has to file anything, because the search works out which notes belong each time it runs.
The idea is older than most note apps. Music libraries have had smart playlists for decades, file managers have smart folders, and email clients have saved filters. It keeps coming back because it removes a whole category of work. A saved search has no filing step, so there is no filing step for you to forget.
Once you have saved searches, tags do a different job. Without them, a tag is a destination: you click #acme to see the Acme notes. With them, a tag becomes an input to a query: a label you attach so that a question you care about can find the note later.
That shift rewards exactly the tagging discipline most organizing advice recommends anyway: a small, closed vocabulary of recurring dimensions such as status, type, and project (the argument is laid out in Tags vs. Folders vs. Links). A tag used once is useless as a query input. A tag like #decision, used on every note that records a choice, turns "what have we decided?" into a question you can save.
It also changes when you tag. At capture time you don't have to decide where a note lives, only which questions it should answer. That is a lighter decision, and you can usually make it in a couple of seconds.
Text and tags work well together. A search for "invoice" filtered to #acme finds the billing threads for one client without a dedicated billing folder. Most of the value of a nested folder hierarchy comes from combining two dimensions like this, and a saved search does it without committing a note to one location.
Not every search deserves a permanent place. The test has two parts: you have asked the question at least three times, and the answer keeps changing. If you have asked only once, it is a search, not a saved search. If the answer never changes, what you want is a link to a specific note.
The questions that usually pass:
#waiting tag on anything you have handed off, saved as a search, gives you a follow-up list that never needs updating by hand.#inbox, #toread, #draft: whatever marks material you captured but haven't dealt with yet.#decision, which becomes invaluable six months later when someone asks why things are the way they are (see the decision log for why that record matters).The ones that usually fail: topics that plain search already finds instantly, one-off research questions, and elaborate queries built for a situation that came up once. Those clutter the list and train you to ignore it.
A good saved search shows a number next to its name: how many notes, or how many tasks, currently match. It looks like a minor interface detail, but it changes how you use the list.
For most saved searches, the number is a gauge that is supposed to go down. Open tasks on a project, items on the reading queue, things you're waiting on. You can read the state of your commitments down the sidebar without opening anything: the launch has four open tasks, the inbox has twenty-three items and is getting out of hand, nothing is waiting on anyone. When a number that should shrink keeps growing, it shows you where attention is needed before anything slips.
This is also what makes a weekly review fast. Much of a review is rebuilding the same views every week: open tasks by project, stalled drafts, pending follow-ups. With those views saved, the review turns into reading down a list of numbers and opening the ones that look wrong. The part of the review that used to be setup disappears, and the fifteen minutes go to deciding what to do instead.
A saved search can return two different things, and it helps to keep them apart. A notes view returns whole notes: the meeting records for a client, everything mentioning a person. A task view returns only the checkbox items inside those notes: the open to-dos for that client, grouped by when they are due.
The second one matters more than it first appears. It is what lets a note app replace a separate project manager. If each project is a tag, then a saved task view filtered to that tag is the project's to-do list. It is built from tasks written where they came up, in meeting notes and journal entries, each with its surrounding context one click away. Nothing gets copied into another tool. The case for keeping tasks inside your notes is made in To-Do Lists in Your Notes, and a saved task view is the piece that makes it scale past a single project.
In Indenta, both kinds live in the same place. Run a search in the sidebar, with text, a tag filter, or both, and press the bookmark icon to save it. It then sits in the sidebar with an always-current count, and one click re-runs it. Do the same while the task view is open and you save a task view instead, for example the open #launch tasks grouped by due date, with a live count of what's left. The User Guide covers the details.
Saved searches can sprawl just like folders and tags. Twenty of them in a sidebar become background noise, and you stop reading the counts. Aim for five to eight, roughly one per active project plus a few standing questions like waiting-on and inbox.
Pruning is painless, and that is the other big advantage over folders. Deleting a saved search loses nothing, because the notes never moved: they are still tagged, still searchable, still where you wrote them. When a project ends, remove its search. If you haven't clicked a search in a month, remove that too. If you need it again, recreating it takes ten seconds. Compare that with dismantling a folder, where every note inside needs a new home.
You don't need to design a set of saved searches up front. Notice which searches you actually repeat. The third time you type the same query, or apply the same tag filter, save it. Give it a name that states the question ("Launch: open tasks", "Waiting on others") rather than a vague label, so that the name and the count together read as a status line.
After a few weeks you'll have a short list that reflects what you actually work on. It stays accurate without any upkeep and shrinks when projects end. It is the one part of your organizing system you never have to maintain.
Try it in practice: Indenta is a free, offline-first outliner — nested notes, backlinks, tags, and peer-to-peer sync, with no account required. Start writing in your browser, or read the User Guide first.