Reference Glossary
Saved search
A stored search query — keywords, filters, and facets — that a user can re-run on demand, without it acting as a shared, always-updating collection object.
Why it matters in a DAM
A DAM user who regularly needs the same slice of the library — say, brand = Acme AND resolution > 3000px AND usage_rights = web — doesn't want to rebuild that filter combination every session, so saving it as a query saves repeated setup work. Unlike a smart collection, most DAM platforms scope a saved search to the individual account by default, so it's a personal shortcut rather than a shared team resource.
A worked example
Common mistake
A team member assumes a colleague's saved search is visible to the whole team and builds a workflow around "the hero images search," only to find it doesn't exist for anyone else — because most DAMs default saved searches to private and require an explicit share or promotion to a shared collection.
A saved search stores the query itself — the keywords, filters, and facet selections a user assembled — so it can be re-run later with one click instead of being rebuilt from scratch. Because it re-executes the search rather than storing a fixed list of results, a saved search always reflects the library as it currently stands, the same way a smart collection does. The practical difference is scope and intent: a saved search is typically a personal convenience tool, while a smart collection is usually built to be a shared, named resource other people browse.
In day-to-day DAM use, saved searches are what let a repeat task — a photo editor pulling this week’s newly approved product shots, a legal reviewer checking assets nearing rights expiry — stay a one-click action instead of a five-filter reconstruction every time. That efficiency gain is small per use but compounds across a team doing the same lookup daily.
The failure mode is almost always a scoping assumption: someone treats their own saved search as institutional knowledge and references it in a process document, not realizing colleagues can’t see it without an explicit share. Teams that want a search to function as shared infrastructure should promote it to a smart collection rather than rely on saved-search visibility defaults.
Frequently asked
What is a saved search?
A saved search stores a query — keywords, filters, and facet selections — so it can be re-run with one click instead of being rebuilt from scratch each time, for example brand:Acme AND usage_rights:web AND resolution:>3000px.
Is a saved search the same as a smart collection?
No. Both re-run live against the current library rather than storing a fixed list of results, but a saved search is typically a personal convenience tool scoped to the user who created it, while a smart collection is usually built to be a shared, named resource other people browse.
Who can see a saved search by default?
Only the user who created it. Most DAM platforms scope a saved search to the individual account by default, treating it as a personal shortcut rather than a shared team resource — it isn't automatically visible to teammates, managers, or other departments, even when it captures a query the whole team could benefit from reusing. That default is why a saved search shouldn't be treated as institutional knowledge on its own: making it visible to anyone else always requires an explicit share, or promoting it into a smart collection built to be shared.
What mistake do teams make around saved-search visibility?
Someone references a colleague's saved search, like "the hero images search", in a process document or workflow, only to find it doesn't exist for anyone else because it was never explicitly shared or promoted.
How should a team make a search available to everyone?
By explicitly promoting it, not by assuming a colleague will stumble onto it. Because a saved search defaults to private, the reliable path is to rebuild the same query as a smart collection — a resource designed to be shared and named so the whole team or department can browse it. That conversion should be a deliberate step taken by whoever owns the search; otherwise the query stays locked to one account no matter how often it's referenced in a workflow document.
What kind of DAM tasks benefit most from saved searches?
Repeat lookups like a photo editor pulling this week's newly approved product shots, or a legal reviewer checking assets nearing rights expiry — a small time savings per use that compounds across a team doing the same lookup daily.