A saved search is a query you build once and store as a named entry — and the DAM re-runs it live every time you open it, always showing whatever currently matches. New assets that fit appear on their own; ones that no longer fit drop out. It is a smart folder that fills itself, with no manual upkeep.
In plain English
You build a filter once — say, “spring campaign, RAW, cleared for web, this year” — and instead of running it and forgetting it, you save it under a name. From then on it sits in the sidebar like a folder, but a folder whose contents are computed, not placed. Shoot ten more assets that match the criteria and they are simply in it the next time you look; archive one and it is gone. Nobody moved anything.
That “computed, not placed” quality is the whole idea. A faceted filter you tick this morning is gone when you close the window; a saved search is that same narrowing made permanent and self-updating. It is why saved searches show up as a scored capability in how a serious DAM is judged, alongside filters and speed.
A saved search is not a collection
This is the distinction that decides which one you should use, and the two are easy to confuse because both look like a folder in the sidebar.
- A collection is curated by hand. You add each asset deliberately, and it stays exactly as you left it until you change it. Membership is a choice.
- A saved search is defined by criteria. Its members are whatever matches the query right now — you never add or remove anything. Membership is a rule.
Use a collection when the set is “these specific assets I picked” — a hand-chosen selection for a client, an approved set for a launch. Use a saved search when the set is “everything that matches this condition” — and you want it to stay current without touching it. A collection is a playlist; a saved search is a filter that never stops running.
Why it matters in a DAM
Saved searches turn the questions you ask a library repeatedly into one click. “New assets awaiting review.” “Everything for this campaign.” “RAW files with no keywords yet.” “Photos whose licence expires in the next thirty days.” Each is a filter you would otherwise rebuild by hand every time; saved once, each becomes a permanent, always-current view.
That last example is worth pausing on, because a saved search can be a safety net, not just a shortcut. A stored query for rights expiring soon, or for assets missing a required field, surfaces a problem proactively — it is sitting in the sidebar showing a count — rather than waiting for someone to remember to go looking. The proactive version is where the real value is.
One dependency, the same one faceted search has: a saved search is only as good as the metadata it queries. If tagging is inconsistent, or a controlled vocabulary isn’t enforced, the query silently misses assets and its count lies. Saved searches reward tagging discipline; they don’t replace it.
Buyer’s test: in a trial, save a search that combines three or four fields, then add a new asset that matches and confirm it appears in the saved search without you touching it. Then check two things: can the saved search be shared with the team so everyone sees the same live view, and does it work in the web client, not only a desktop app. A saved search nobody else can open is half a feature.
Related terms
See it in action
Our search-speed ranking tests whether stored, stacked queries stay fast on a large catalog, and the version-control ranking covers Daminion, where saved searches, batch tagging and version history all now work in the web client rather than only the desktop app.
FAQ
What is a saved search in a DAM?
A saved search is a query you build once - a combination of filters like project, file type, rights status and date - and store as a permanent, named entry. Each time you open it, the DAM re-runs the query and shows whatever currently matches, so newly added assets that fit appear automatically and ones that no longer fit drop out. It is often called a smart folder or smart collection because it behaves like a folder that fills itself.
How is a saved search different from a collection?
Membership. A collection is curated by hand - you add each asset to it deliberately, and it stays exactly as you left it. A saved search is defined by criteria - its members are whatever matches the query right now, with no manual adding or removing. Use a collection when the set is 'these specific assets I chose'; use a saved search when the set is 'everything that matches this rule.' A collection is a playlist; a saved search is a filter that never stops running.
What are saved searches actually used for?
Recurring questions you ask the library often. 'New assets awaiting review,' 'everything for this campaign,' 'photos whose licence expires in the next 30 days,' 'RAW files with no keywords yet.' Instead of rebuilding the same filter every time, you save it once and open it like a folder. The expiry example doubles as a safety net: a saved search for lapsing rights surfaces a problem before it becomes a liability, rather than waiting for someone to think to look.
Do saved searches need good metadata to work?
Yes - the same dependency as faceted search. A saved search is only as reliable as the fields it queries. If assets aren't tagged consistently, or a project name has three spellings, the query misses things and its results can't be trusted. Saved searches are a payoff for tagging discipline and a controlled vocabulary, not a substitute for them.
Can a saved search be shared with a team?
On the better tools, yes, and it is worth checking. A saved search shared across the team means everyone opens the same live view - 'assets awaiting approval' or 'this quarter's launch set' - without each person rebuilding it. In our testing, saved searches are part of what a capable DAM offers alongside faceted filters and version history, increasingly in the web client rather than only a desktop app.