What Is Object Context?
Object Context is a block of instructions attached to a specific Salesforce object inside the Conversational Agent. It tells the agent how to interpret user requests, map natural language to field names, respect picklist values, and avoid mistakes specific to that object.
You need Object Context when an object has any of:
- Custom or non-obvious field names
- Controlled picklist values the agent must not invent
- Relationships to other objects that affect searching or writing
- Business rules that override default agent behavior
- Domain vocabulary that differs from API names
How to Access Object Context
Admin Settings is the central control panel for configuring the Ascendix Conversational Agent. To access it, go to the App Launcher and search for Agent Settings
Object Context Instructions are managed under the Persona & Object Context tab.
Structure of an Object Context Block
| Section | Purpose |
| Purpose / Scope | What this object is; what the agent may and may not do with it. |
| Core Rules / Constraints | Hard limits: picklist values, data type rules, forbidden fields, mandatory preconditions. |
| Searching / Reading | How to map search criteria from natural language to fields and relationships. |
| Creating / Updating | Field mapping for writes: required fields, forbidden legacy fields, role/type tables. |
| Synonym Normalization | Maps user vocabulary to API field names. |
| Output Rules | What to return, what to hide, what confirmation fields to include. |
How to Write Each Section
Purpose / Scope 3–5 sentences. State what the object represents, which operations are allowed (create / read / update / delete), and any hard boundaries on what the agent may return or surface.
Core Rules / Constraints List non-negotiable rules. Be specific — vague rules produce unpredictable behavior.
- Enumerate every valid picklist value explicitly.
- State data-type requirements for any fields with formatting constraints.
- Name forbidden fields by API name.
- State any mandatory preconditions (e.g., "always identify the customer by email before any action").
Process for a New Object
- Understand the object — purpose, allowed operations, related objects.
- Audit the schema — fields users will reference, all picklist values, required and forbidden fields.
- Map user language — list synonyms for every important field.
- Identify cross-object filtering — define relationship paths and OR/AND logic.
- Review failure modes — missing location filter, invalid picklist value, required field missing on create.
Template Examples
Purpose / Scope
[What the object is; which operations are allowed; what must not be returned]
1) Core Rules / Constraints
- Picklist: FieldName__c — only "Value A", "Value B", "Value C"
- Data types: [e.g., any formatting constraints on field values]
- Always do: [e.g., identify customer by email before any action]
- Never use: [LegacyField1__c, LegacyField2__c]
2) Searching / Reading
- Named city/state → filter via [Relationship__r.FieldName__c]; use OR across plausible fields
- Range fields: define min/max mapping and how informal values should be expanded
- "[user phrase]" → FieldName__c = "[ExactPicklistValue]"
3) Creating / Updating
- Always include: [required fields; derive Name from X if not provided]
- [UserTerm] → CanonicalField__c; Role__c = "[PicklistValue]"
- Never populate: [LegacyField1__c, LegacyField2__c]
- Picklist fallback: if value not in schema, use "Other"
4) Synonym Normalization
[user term] → [API field or concept]
5) Output Rules
- Always include: [Field1__c, Field2__c]
- Do not return: [related object records used only for filtering]
- Confirm applied filters by including relevant fields in results
— End —