Elements

Metrics, formulas, filters, and enrichments are one library — the element library: reusable pieces of context, defined once and added by API name to any number of entities.

The four types

	Metric	Formula	Filter	Enrichment
Produces	A rollup over related records	A computed value from the record	A named, reusable condition	Values and/or record tables
Cost	Batched into one query	None — no query	None — it shapes queries	A query or more, per record
Default minimum level	list	list	— (not rendered)	detailed
Defined by	Relationship + function + filters	A formula expression	Conditions on the object	A source: Apex, invocable, or flow

Three of the four render onto payloads. A filter is different in kind: it never appears in a payload — it is part of the entity’s query contract, passed by name in Find Records. See Named filters.

Every element has a label (what the value is called in the payload), an API name (how entities refer to it, fixed after creation), an optional instruction rendered with the value, optional synonyms, a minimum level, Available for (which objects it may be used on; empty means any) and Where used.

Define once, use many times

One definition serves many entities. Change a metric’s filter and every entity using it returns the new result on its next call, with no second copy to find and no activation anywhere. Entities are versioned; elements are not, so a version freezes which elements an entity uses, never what they compute. The edit dialog warns you when a definition is shared.

Available for limits which objects an element may be used on; Where used shows actual usage. An element added to an entity outside that list is skipped with a warning on the Issues page rather than failing the payload.

Metrics

A rollup over child records — count, sum, average, min or max, with optional filters: SUM of Opportunities.Amount where IsClosed = false. When an agent needs how many or how much, one number beats twenty-five rows, which is why metrics default to list level. The engine batches every metric on a payload into one query, so ten cost roughly what one costs. → Building metrics

Formulas

A standard Salesforce formula evaluated against the record already loaded: Amount * Probability / 100. No extra query, and any field the expression names is added to the entity’s query for you. Percent fields evaluate as fractions, so 100% is 1.0. → Building formulas

Filters

A named condition you write once — open, committed — so your org’s definition of a business word answers instead of the model’s guess. Advertised in the catalog with its meaning; composed by AND in Find Records; allowed to use fields that are not individually filterable, because you wrote the condition rather than the caller. See Named filters.

Enrichments

Computed context from a source:

Source	What it mounts
Apex Provider	A class implementing EntityEnrichmentProvider. Also how a Data 360 DTO registers
Invocable Action	Any existing @InvocableMethod, unchanged
Flow	Any active autolaunched flow, unchanged
Data 360 (planned)	Declarative queries over Data 360 objects
External Objects (planned)	OData-backed __x objects

Output lands as labeled values or record tables. Record results are re-queried as the calling user. A failing source never fails the payload; it becomes an issue on Issues. → Building enrichments · Provider SPI

Choosing between them

You want…	Use
A count or total over child records	Metric
Arithmetic over fields on this record	Formula
A business word agents can filter by — “open”, “committed”	Filter
The actual child rows	Related list — not an element
A value only your code can compute	Enrichment (Apex provider)
Something an existing flow or action already returns	Enrichment (flow or invocable)
A parent record’s details inline	Reference — not an element

If a metric and a formula could both produce it, prefer the formula — it costs no query.

What’s next

• Domains — several entities under one name.