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.

How it works

A named filter may use fields that aren’t individually filterable. You wrote the condition, so it can reach an indexed compound or a sensitive flag an agent could never filter on directly.

ContextWorks checks caller-written filters against the entity’s filterable surface; a named filter resolves after that check, by name, from the stored definition — never parsed from anything the caller sent. Everything runs in user mode: a named filter never widens what the caller can see.

Defining one

A filter is a set of conditions, ANDed, built with the same filter builder related lists and metrics use. Plus two sentences:

  • 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. It’s required: a condition only means something against one object’s fields.

Add it to an entity

A filter answers nothing until an entity carries it. Two ways:

  • The element’s Where Used tab
  • + Add Filter on an entity’s canvas, under Metrics

If the canvas dropdown shows no filters, every applicable one is already added or none apply to this object — check Available For.

Like every element, Activate freezes which entities carry the filter into each entity’s version. The condition itself stays 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. An unknown name refuses with the valid set named.

Notes

open on the Pipeline entity and open on the Finance entity are the same filter. Edit it once and both answer alike. 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