· 6 min read · Filters

How to find any task fast with filters and Query Search

A backlog you can't search is a backlog you re-litigate in meetings. Here's how quick filters and saved Query Search turn "where's that ticket?" into one click.

filters search backlog productivity project management
How to find any task fast with filters and Query Search

Every team has the same ghost meeting. Someone asks "what's actually left for the release?" and three people start scrolling. One opens the board and eyeballs it. One remembers a ticket that might be a duplicate. One says "let me check" and never comes back. Ten minutes evaporate reconstructing a picture the tool already has — it just wasn't asked the right question.

That's not a backlog problem. It's a search problem. The issues are all there, tagged and assigned and statused, but the knowledge of how to slice them lives in one person's head instead of in a saved query anyone can click. When finding work is manual, the answer to "what's the state of things?" is always a person's best guess, and best guesses are how release dates slip.

This post is about closing that gap. Not with a new process or a weekly hygiene ritual, but with two tools most teams underuse: fast one-click filters for the everyday, and a real query language for the questions that matter. Get these right and "where's that ticket?" stops being a conversation.

Quick filters are for speed, Query Search is for precision

There are really only two kinds of question you ask a backlog, and they want two different tools.

The first kind is fast and shallow: just my stuff, just this sprint, just the bugs. You ask it fifty times a day and you want the answer in one click, no typing. That's what quick filters are for — one-click toggles on top of any board or list, no syntax, no thinking. Stack a couple together ("my issues" + "in progress") and the board collapses to exactly what you're working on right now.

The second kind is precise and occasional: everything blocking the release that isn't assigned and hasn't moved in a week. You can't click your way to that. You need a query. your.team's Query Search gives you the full query language — fields, operators, ordering and boolean logic:

project = YT AND status = "In Progress" AND assignee is empty

The mistake is reaching for the wrong one. People either try to hand-craft a query for a question a single click would answer, or they scroll a board hunting for something only a query can isolate. A good rule of thumb:

You want... Reach for Why
My work, right now Quick filter One click, muscle memory, zero syntax
This sprint's bugs Quick filter Common enough to be a toggle
Everything unassigned in QA over 3 days old Query Search Multiple fields and a condition — needs the language
A view your whole team reuses Saved Query Search Perfect it once, share it forever

The two compose, too. You can stack quick filters on top of a Query Search base — start from the precise slice, then click to narrow further without rewriting the query. Precision when you set it up, speed when you use it.

The rule: if you searched for it twice, save it

Here's the habit that changes everything, and it costs nothing: the second time you build the same query, save it.

Most teams treat search as disposable. You type out the conditions, get your answer, close the tab, and rebuild the whole thing from scratch tomorrow. That's fine once. By the third time it's pure waste — and worse, it means everyone on the team is independently reinventing the same query, slightly differently, getting slightly different answers to the same question.

Saved filters fix that. Perfect a query once and it becomes a named, shareable object the whole workspace can use. "Release blockers," "unassigned bugs," "my review queue," "stale in-progress" — each is a question the team asks constantly, answered identically for everyone, because they're all clicking the same saved query instead of typing their own version.

A few that earn their keep on almost any team:

  1. Release blockers. Everything tagged for the current release that isn't Done. This is the query that kills the ghost meeting — one click and the "what's left?" question answers itself.
  2. Unassigned and unloved. Open issues with no assignee. Run it at the end of standup and nothing falls through the cracks.
  3. Stale in-progress. Cards in "In Progress" that haven't moved in N days. This is where your real WIP problems hide — work that's technically started but actually stuck.
  4. My review queue. Everything waiting on you specifically, not the whole team's firehose. The antidote to "I didn't know you were waiting on me."
  5. Recently reopened. Issues that went back from Done to something earlier. A quiet quality signal most dashboards miss.

Pin the two or three you live in and they're one click away, every day, on every board.

Shared filters are how a team agrees on reality

There's a deeper reason to save and share queries, and it's not just saving keystrokes. A shared filter is a shared definition.

When "release blockers" is a saved query the whole team clicks, everyone is looking at the same list, built from the same rules. Nobody's version of "blocker" is subtly different. The lead, the PM and the engineer all see the same seven cards, so the conversation is about the work, not about whose filter is right. That agreement is worth more than the time savings — it's the difference between a status meeting and an argument.

This is also what makes your other tooling honest. Good reports and burndowns assume the data underneath is complete and consistently sliced. A team that all filters differently produces numbers nobody trusts. A team that shares its filters produces one picture, and decisions get faster because there's nothing to reconcile first.

The best part: filters are unlimited on every plan, including Free. There's no quota to ration, no "you've hit your saved-search limit." Save the query for every recurring question you have. The cost of a filter you rarely use is nothing; the cost of a question your team can't answer in one click is a meeting.

A ten-minute setup that pays off for months

You don't need a project to make this work. Spend ten minutes once:

  • List your recurring questions. Whatever you or your team asks the backlog every week — "what's left for the release," "who's overloaded," "what's stuck." Aim for five to eight.
  • Build each as a Query Search and save it. Name it in plain language, the way someone would ask it out loud. assignee = me AND status = "In Review" becomes "My review queue."
  • Share the team-wide ones across the workspace so nobody rebuilds them.
  • Pin your daily three so they're one click from any board.
  • Delete the ones you never click after a couple of weeks. A short, trusted list beats a long, stale one — the same discipline that keeps a board legible keeps a filter list useful.

Do this once and the "where's that ticket?" scramble mostly disappears. The knowledge of how to see your work stops living in the fastest scroller's head and starts living in a query anyone can click.


Stop reconstructing the same view over and over. Filters give you one-click quick filters for the everyday and full Query Search for the precise questions — saved, shared and unlimited on every plan. Start free and save your first query today.

Put it into practice.

Everything in this post is built into your.team — free from your first workspace.