Polymorphic Relationships
Task.WhoId, Task.WhatId, Event.WhoId and Event.WhatId. REDA AI handles these safely in record context and exposes a single agent setting that controls how strict the runtime is when something can’t be resolved.
Why This Matters
Most lookup fields target a single object — Account.OwnerId always points to a User. But Salesforce ships several polymorphic lookup fields whose target depends on the row:
| Field | Possible targets |
|---|---|
Task.WhoId |
Contact, Lead |
Task.WhatId |
Account, Opportunity, Case, Campaign, Contract and several others |
Event.WhoId |
Contact, Lead |
Event.WhatId |
Account, Opportunity, Case and other related objects |
FeedItem.ParentId |
Any feed-enabled object |
Custom polymorphic fields can also be defined in your org. The constraint is the same wherever they appear: SOQL can’t blindly traverse a relationship Name on these fields because the platform doesn’t know in advance which object’s Name to read.
How REDA AI Handles Them
When the platform builds record context for an agent, it loads the configured Field API Names plus — if Include Related Names is on — an automatic Relationship.Name for each lookup. The auto-Name expansion is gated by a single rule:
The platform auto-expands Relationship.Name only for lookups whose target is a single object. Polymorphic lookups (multiple targets) are skipped quietly — the lookup Id is included, but the Name is not.
This is a deliberate guard. Without it, a query that includes WhoId.Name would error on rows where the WhoId points to a Lead instead of a Contact (or vice versa), because the SOQL is constructed once for the whole batch.
What the agent sees
- For non-polymorphic lookups — the agent sees both the Id and the Name (e.g. OwnerId: 005…, Owner Name: Jane Smith).
- For polymorphic lookups — the agent sees the Id but not the Name. If the agent needs the Name, it can query for it on demand using a built-in tool such as
get_record.
For domain models built around Tasks or Events, this means the agent gets the activity record cleanly but has to take an extra step to identify the Contact, Lead or related record by name. That step costs a tool call but keeps the runtime predictable.
Strict vs Degraded Mode
Beyond the polymorphic guard, the platform exposes one agent-level setting that controls how strict the record-context build is when individual fields can’t be loaded:
| Setting | Where | Default |
|---|---|---|
| Allow Degraded Record Context | On the Agent Definition record | Off (strict) |
Strict mode (default)
With the setting off, the platform requires every configured context field to be loadable. If a configured field has been deleted, renamed, or blocked by field-level security (FLS) for the running user, the platform aborts the agent run with an error. This is the safest default for internal agents that need consistent context to make decisions — the conversation fails fast rather than producing answers from a partial picture.
The setting has a second, more common trigger: no configuration at all. If an agent is pointed at an object that has no active Context Field record, strict mode does not degrade — it stops the run with:
“No active Context Field configuration found for <Object>. Configure a
REDAAI_Context_Field__c record or enable Allow Degraded Record Context on the agent.”
This is the usual cause of a new agent failing on an object nobody has configured yet, and because strict
is the default it happens out of the box. With the setting on, REDA AI instead falls back to a built-in
field list — StageName, Status, Type, Priority,
Subject, CloseDate, Amount, Phone, Email,
Industry, OwnerId, CreatedDate — capped at 10 fields, keeping
older agents working. Whichever fields of that list the object happens to have are the ones it gets, which
is why a real configuration is still the right answer.
Degraded mode
With the setting on, the platform logs a warning incident and proceeds with whatever fields it could load. The agent keeps running with degraded context. This is the right choice for customer-facing or API-driven agents where partial context is acceptable and where some fields are intentionally hidden from certain user profiles.
Two boundaries always apply, even in degraded mode:
- The record itself must be readable. If the running user has no read access to the record at all, the run aborts.
- The object must be accessible. Object-level CRUD denial isn’t something the platform can degrade past.
How to Pick the Setting
| Use strict (off) when… | Use degraded (on) when… |
|---|---|
| The agent makes consequential decisions and must see complete context. | Some users have FLS restrictions that the agent should gracefully work around. |
| You want failures to be loud and immediate during testing. | The agent runs on customer-facing or API channels where a soft failure is preferable to a hard error. |
| The configured fields are stable and you control the schema. | The same agent runs across many user profiles with different access patterns. |
The setting can be flipped at any time on the Agent Definition; effect is immediate on the next conversation.
Custom Polymorphic Fields
If your org defines custom polymorphic lookups (multiple Reference To targets on a custom field), the same single-target rule applies — auto-Name expansion is skipped on those fields. Treat them like the standard polymorphic fields:
- Include the lookup Id in the field list when the agent needs to know which record is referenced
- Don’t expect a Relationship.Name to come along for free
- If the agent regularly needs the related Name, give it a tool that resolves the Id to a Name on demand
Configuring Activity-Centric Agents
Agents that primarily work with Tasks or Events can still use those records as context — the polymorphic limitation only affects the auto-Name expansion of WhoId and WhatId, not the rest of the record. A few patterns work well:
Include the type alongside the Id. When the field WhoId is in the context, also include Who.Type if you have it — the agent can then decide whether to query the matching object for a name.
Restrict to one target where possible. If the agent only ever cares about Contact-related Tasks, filter at the source (e.g. via context fields on the parent object instead of the Task).
Use a focused Apex tool for resolution. An Apex Class tool that takes a polymorphic Id and returns the Name plus type is a clean way to give the agent on-demand resolution without bloating the record context.
Best Practices
Don’t fight the guard. The single-target rule is there to prevent intermittent runtime errors. Trying to force Name expansion on polymorphic fields by adding them to the field list manually won’t change the behaviour — the platform still gates the expansion.
Default to strict. Most agents are easier to debug when they fail loudly on missing fields. Switch to degraded mode deliberately, for the channels and user profiles where you understand why fields might be missing.
Use the Conversation Debugger to inspect. The Debugger shows the exact context the agent received. If the agent says it doesn’t know who a Task is for, check the Debugger first — the Id is probably there, but the Name is intentionally absent.
Include explicit type information when available. Who.Type and What.Type tell the agent what object the polymorphic Id points to without an extra query. That’s usually enough for the agent to decide the next step.
Frequently Asked Questions
Not safely. The platform skips auto-Name expansion on polymorphic lookups specifically because SOQL can’t generically resolve a Name across multiple target objects. If the agent needs the Name, it should call a tool to resolve it on demand.
Yes, when they’re relevant to the agent’s purpose. The recommendation includes the lookup Id but doesn’t change the runtime expansion behaviour — auto-Name expansion is still gated by the single-target rule.
In strict mode the run aborts with an error. In degraded mode the platform logs a warning, drops the inaccessible field from the context, and continues. The conversation transcript shows what the agent actually saw.
It also covers fields that have been deleted or renamed since the Context Field record was configured. Polymorphic-field handling is a separate guard that applies in both modes — the setting doesn’t change it.
Yes — this is the recommended pattern. The built-in get_record tool can resolve a known Id to its full record, including the Name. Or you can ship a focused Apex Class tool that takes a polymorphic Id and a target type and returns the Name.
Yes. In strict mode the abort produces an Incident Log entry. In degraded mode each missing-field event produces a warning incident. The conversation record always reflects the context the agent actually received.
Next Steps
Read Adding Context Fields for the full Context Field record lifecycle, or revisit Context Field Optimizer for AI-assisted recommendations.