Named filters

Business words don’t map cleanly to fields. An agent asked for “open deals” guesses IsClosed = false — wrong for an org that excludes renewals, or that counts only certain record types. A named filter writes the org’s definition down once — open, committed, at_risk — so agents pass the word and get your meaning.

Named filters live in Build → Filters, the fourth element library beside Metrics, Formulas, and Enrichments: defined once, constrained to one object, added to entities by API name, with Where Used showing every consumer.

Defining one

A filter is a set of conditions, ANDed, built with the same filter builder related lists and metrics use — plus the two sentences that make it worth having:

  • Description — what the filter means, shown in the catalog: “Deals still in play — not yet closed either way.”
  • Instruction (the Meaning tab) — the pragmatics an agent needs: “excludes renewals; sales ops trues forecast categories up weekly, so mid-week this can lag.”

Available For names the object the condition reads — required, because a condition only means something against one object’s fields. Add it to entities on the Where Used tab; like every element, which entities carry it is frozen into the entity’s version at Activate, while the condition itself is live — edit it and every consumer answers with the new definition on its next call.

How agents use them

The catalog’s entity detail lists each named filter with its description and instruction — that’s how an agent learns open exists instead of inventing its own condition. Find Records takes them in filterNames, comma-separated, and they compose by AND:

filterNames: open,committed,this_period

is open AND committed AND closing this period — expressive questions from simple pieces, with the complexity in curated definitions rather than agent-constructed JSON. An unknown name refuses with the valid set named.

The trust property

A named filter may use fields that are not individually filterable. You wrote the condition, so it can reach an indexed compound or a sensitive flag an agent would never be allowed to probe — exposure narrows and capability widens at once.

That works because the two are kept apart: caller-written filters pass through the filterable-surface gate; named filters resolve after it, by name, from the stored definition — never parsed from anything the caller sent. Everything still runs in user mode: a named filter never widens what the caller can see.

One definition, many entities

open on the Pipeline entity and open on the Finance entity are the same filter — edit it once and both answer alike, which matters more here than for a metric: two copies that drift change which rows come back, not just a number. A skill that says “call Find Records with open” stays correct across every entity that adopts the filter, even as the definition evolves underneath.

What’s next