Fields
The curated field list — which fields an agent sees, at which level, in what order.
Open the picker
In the entity builder, click the Core Record card.
Each row is a field with five checkboxes — List, Standard, Detailed, Filter, Write — and a per-field instruction. Counts against each level’s cap (10 / 20 / 30) are shown as you go. → Levels
The level checkboxes decide what an agent receives; Filter and Write decide what it may ask and change:
- Filter — the field is accepted in Find Records filters and
sortBy. Untouched, it follows the Detailed checkbox; ticking or clearing it records an explicit declaration, so returning and filtering move independently. A field declared filterable but in no level appears below the table as a filter-only pill — agents screen on it, it’s never returned. → The filterable surface - Write — the field is declared writable for Update Records. Admin-only, and inert until the entity and org write switches allow. → Write access
Suggest Filterable mines your org’s recently-run reports for the fields people actually filter on — matched fields get declared, the rest arrive as filter-only pills. Edit the result; it’s a seed, not a verdict.
Add a field
Click Add Field and search the object’s fields by label or API name. Only fields you can access are listed — if a field is missing, check your own field-level security.
To add a field from a parent record, walk the lookup with the picker breadcrumb — Account.Owner.Name on an Opportunity entity. Use this for one or two high-value parent fields; for several, use a reference instead.
Order the fields
Fields render in exactly the order they appear in the picker, in both markdown and JSON — and order carries weight with an LLM. Put the fields that identify and qualify the record first, supporting detail after.
Drag a row by its handle to reorder, or focus the handle and use ↑ / ↓. There is one roster: reordering applies to all three levels at once.
The rendered field block has no section headers — each labeled value speaks for itself. Summary Metrics and related lists keep their own labels.
Field types
| Type | How it renders |
|---|---|
| Text, picklist | As-is |
| Number, currency, percent | Formatted with separators and symbols; currency respects the org’s settings |
| Date, datetime | Formatted, not raw |
| Checkbox | true / false |
| Lookup | The referenced record’s name where available, otherwise the ID |
| Formula | Its calculated value |
| Address | Postal form on one line |
| Geolocation | latitude, longitude |
| Long text | In full — check the token cost |
Compound fields (BillingAddress, a geolocation) are cheaper than their components: one curated field, one readable string. Use the components when you want only part — say, country alone for routing.
Empty values
A field with no value on a record is omitted from that payload — no dash, no null. This is per record; nothing to configure. Quality measures completeness per field once you have traffic.
Fields added automatically
Two cases need no curation:
- A field a formula references is queried so the expression can evaluate. It renders only if you also curate it.
- The columns a related list or reference needs are queried on those records, governed by their entity’s curation.
Best practices
- Include what changes an answer. If this field were different, would the agent say something different?
Renewal_Date__c— yes.LastModifiedDate— almost never. - Curate
listfirst and hardest. Those fields are the columns this record shows everywhere else. Choose them so a human could identify the record. - Leave out mostly-empty fields. A field populated on 4% of records costs tokens on every load and informs almost none.
- Watch for redundancy.
Amount,Expected_Revenue__c, andWeighted_Amount__ctogether invite the wrong pick. Include the authoritative one and explain it with an instruction. - Include IDs when the agent may act. A workflow that chains into an update needs the record ID in the payload.
Limitations
Removing a field hides it from this view only — a user who can query the object can reach it elsewhere. Use field-level security for access control. The converse is safe: curate in a sensitive field and callers without access to it won’t receive it. → Security
Meaning: label, instruction, synonyms
The Meaning column opens one editor per field. The glyph is filled when something is declared.
| Slot | Use it for |
|---|---|
| Label | What the agent should call this field |
| Instruction | What the value means here → Instructions |
| Synonyms | What people call it, comma-separated |
Synonyms let an agent match the word a user actually typed: put commit, upside, and at risk on a forecast field and a question using any of them resolves. They reach the agent through Get Catalog, so they cost nothing in a payload.
Rename a field for the agent
Set a Label to have the agent read a field by your org’s name for it — Amount as Contract Value, say.
The API name never changes. Get Catalog shows it in its own column beside the label, because filters and writes still speak API names. The picker shows the Salesforce label in grey next to any override, so you can still find the field in setup.
Rename only where the Salesforce label genuinely misleads. A relabel is contract: it ships with the next Activate, and every agent reading that entity sees the new word.
What’s next
- Instructions — attach meaning to what you curated.
- Write access — what agents may change, and the chain that gates it.