Relaciones polimórficas
Task.WhoId, Task.WhatId, Event.WhoId y Event.WhatId. REDA AI los maneja de forma segura en el contexto de registro y ofrece una única configuración del agente que controla qué tan estricto es el tiempo de ejecución cuando algo no se puede resolver.
Por qué es importante
La mayoría de los campos de búsqueda apuntan a un solo objeto — Account.OwnerId siempre apunta a un User. Pero Salesforce incluye varios campos de búsqueda polimórficos cuyo destino depende de la fila:
| Campo | Destinos posibles |
|---|---|
Task.WhoId |
Contacto, Prospecto |
Task.WhatId |
Cuenta, Oportunidad, Caso, Campaña, Contrato y varios más |
Event.WhoId |
Contacto, Prospecto |
Event.WhatId |
Cuenta, Oportunidad, Caso y otros objetos relacionados |
FeedItem.ParentId |
Cualquier objeto habilitado para feed |
También puedes definir campos polimórficos personalizados en tu organización. La restricción es la misma dondequiera que aparezcan: SOQL no puede recorrer a ciegas un Name de relación en estos campos porque la plataforma no sabe de antemano el Name de qué objeto debe leer.
Cómo los maneja REDA AI
Cuando la plataforma construye el contexto de registro para un agente, carga los nombres de API de campo configurados más — si Incluir nombres relacionados está activado — un Relationship.Name automático para cada búsqueda. La expansión automática del Name está limitada por una única regla:
La plataforma expande automáticamente Relationship.Name solo para las búsquedas cuyo destino es un único objeto. Las búsquedas polimórficas (varios destinos) se omiten de forma silenciosa — se incluye el Id de la búsqueda, pero no el Name.
Esta es una protección deliberada. Sin ella, una consulta que incluya WhoId.Name generaría un error en las filas donde el WhoId apunta a un Prospecto en lugar de a un Contacto (o viceversa), porque el SOQL se construye una sola vez para todo el lote.
Lo que ve el agente
- Para las búsquedas no polimórficas — el agente ve tanto el Id como el Name (por ejemplo, OwnerId: 005…, Owner Name: Jane Smith).
- Para las búsquedas polimórficas — el agente ve el Id pero no el Name. Si el agente necesita el Name, puede consultarlo bajo demanda mediante una herramienta integrada como
get_record.
Para los modelos de dominio construidos en torno a Tasks o Events, esto significa que el agente obtiene el registro de actividad de forma limpia, pero debe dar un paso adicional para identificar por nombre al Contacto, al Prospecto o al registro relacionado. Ese paso cuesta una llamada a una herramienta, pero mantiene predecible el tiempo de ejecución.
Modo estricto frente a modo degradado
Más allá de la protección para campos polimórficos, la plataforma ofrece una configuración a nivel de agente que controla qué tan estricta es la construcción del contexto de registro cuando algunos campos no se pueden cargar:
| Configuración | Dónde | Valor predeterminado |
|---|---|---|
| Permitir contexto de registro degradado | En el registro de Definición de agente | Desactivado (estricto) |
Modo estricto (predeterminado)
Con la configuración desactivada, la plataforma exige que todos los campos de contexto configurados se puedan cargar. Si un campo configurado se ha eliminado, renombrado o bloqueado por la seguridad a nivel de campo (FLS) para el usuario que ejecuta el agente, la plataforma cancela la ejecución del agente con un error. Este es el valor predeterminado más seguro para los agentes internos que necesitan un contexto consistente para tomar decisiones — la conversación falla de inmediato en lugar de producir respuestas a partir de una imagen parcial.
El ajuste tiene un segundo desencadenante, más habitual: que no haya ninguna configuración. Si un agente apunta a un objeto que no tiene ningún registro de Context Field activo, el modo estricto no degrada nada: detiene la ejecución con este error:
«No active Context Field configuration found for <Objeto>. Configure a
REDAAI_Context_Field__c record or enable Allow Degraded Record Context on the agent.»
Esta es la causa habitual de que un agente nuevo falle en un objeto que nadie ha configurado todavía y,
como el modo estricto es el predeterminado, ocurre nada más empezar. Con el ajuste activado, REDA AI
recurre en su lugar a una lista de campos integrada — StageName, Status,
Type, Priority, Subject, CloseDate,
Amount, Phone, Email, Industry, OwnerId,
CreatedDate — limitada a 10 campos, lo que mantiene funcionando a los agentes
antiguos. Solo obtiene los campos de esa lista que el objeto tenga realmente, y por eso una configuración
de verdad sigue siendo la respuesta correcta.
Modo degradado
Con la configuración activada, la plataforma registra un incidente de advertencia y continúa con los campos que pudo cargar. El agente sigue ejecutándose con un contexto degradado. Esta es la opción correcta para los agentes orientados al cliente o impulsados por API donde el contexto parcial es aceptable y donde algunos campos se ocultan intencionalmente a ciertos perfiles de usuario.
Siempre aplican dos límites, incluso en modo degradado:
- El registro en sí debe ser legible. Si el usuario que ejecuta el agente no tiene ningún acceso de lectura al registro, la ejecución se cancela.
- El objeto debe ser accesible. La denegación de CRUD a nivel de objeto no es algo que la plataforma pueda sortear degradando el contexto.
Cómo elegir la configuración
| Usa estricto (desactivado) cuando… | Usa degradado (activado) cuando… |
|---|---|
| El agente toma decisiones de peso y debe ver el contexto completo. | Algunos usuarios tienen restricciones de FLS que el agente debe sortear sin problemas. |
| Quieres que las fallas sean evidentes e inmediatas durante las pruebas. | El agente se ejecuta en canales orientados al cliente o de API donde una falla suave es preferible a un error duro. |
| Los campos configurados son estables y tú controlas el esquema. | El mismo agente se ejecuta en muchos perfiles de usuario con diferentes patrones de acceso. |
La configuración se puede cambiar en cualquier momento en la Definición de agente; el efecto es inmediato en la siguiente conversación.
Campos polimórficos personalizados
Si tu organización define búsquedas polimórficas personalizadas (varios destinos en Reference To en un campo personalizado), aplica la misma regla de destino único — la expansión automática del Name se omite en esos campos. Trátalos como los campos polimórficos estándar:
- Incluye el Id de la búsqueda en la lista de campos cuando el agente necesite saber cuál registro se referencia
- No esperes que un Relationship.Name venga incluido de forma gratuita
- Si el agente necesita con frecuencia el Name relacionado, dale una herramienta que resuelva el Id a un Name bajo demanda
Configurar agentes centrados en actividades
Los agentes que trabajan principalmente con Tasks o Events pueden seguir usando esos registros como contexto — la limitación polimórfica solo afecta la expansión automática del Name de WhoId y WhatId, no al resto del registro. Algunos patrones funcionan bien:
Incluye el tipo junto al Id. Cuando el campo WhoId está en el contexto, incluye también Who.Type si lo tienes — así el agente puede decidir si consulta el objeto correspondiente para obtener un nombre.
Restringe a un solo destino cuando sea posible. Si al agente solo le importan las Tasks relacionadas con Contactos, filtra en el origen (por ejemplo, mediante campos de contexto en el objeto principal en lugar de en la Task).
Usa una herramienta de Apex específica para la resolución. Una herramienta de clase Apex que toma un Id polimórfico y devuelve el Name más el tipo es una forma limpia de darle al agente resolución bajo demanda sin sobrecargar el contexto de registro.
Prácticas recomendadas
No luches contra la protección. La regla de destino único existe para prevenir errores intermitentes en tiempo de ejecución. Intentar forzar la expansión del Name en campos polimórficos agregándolos manualmente a la lista de campos no cambiará el comportamiento — la plataforma sigue limitando la expansión.
Usa estricto por defecto. La mayoría de los agentes son más fáciles de depurar cuando fallan de forma evidente ante campos faltantes. Cambia al modo degradado de forma deliberada, para los canales y perfiles de usuario donde entiendes por qué podrían faltar campos.
Usa el Depurador de conversaciones para inspeccionar. El Depurador muestra el contexto exacto que recibió el agente. Si el agente dice que no sabe para quién es una Task, revisa primero el Depurador — probablemente el Id esté ahí, pero el Name está ausente de forma intencional.
Incluye información de tipo explícita cuando esté disponible. Who.Type y What.Type le dicen al agente a qué objeto apunta el Id polimórfico sin una consulta adicional. Eso suele ser suficiente para que el agente decida el siguiente paso.
Preguntas frecuentes
No de forma segura. La plataforma omite la expansión automática del Name en las búsquedas polimórficas precisamente porque SOQL no puede resolver de forma genérica un Name entre varios objetos de destino. Si el agente necesita el Name, debe llamar a una herramienta para resolverlo bajo demanda.
Sí, cuando son relevantes para el propósito del agente. La recomendación incluye el Id de la búsqueda, pero no cambia el comportamiento de expansión en tiempo de ejecución — la expansión automática del Name sigue estando limitada por la regla de destino único.
En modo estricto, la ejecución se cancela con un error. En modo degradado, la plataforma registra una advertencia, descarta el campo inaccesible del contexto y continúa. La transcripción de la conversación muestra lo que el agente vio realmente.
También cubre los campos que se han eliminado o renombrado desde que se configuró el registro de Campo de contexto. El manejo de los campos polimórficos es una protección independiente que aplica en ambos modos — la configuración no lo cambia.
Sí — este es el patrón recomendado. La herramienta integrada get_record puede resolver un Id conocido a su registro completo, incluido el Name. O puedes ofrecer una herramienta de clase Apex específica que toma un Id polimórfico y un tipo de destino y devuelve el Name.
Sí. En modo estricto, la cancelación genera una entrada en el registro de incidentes. En modo degradado, cada evento de campo faltante genera un incidente de advertencia. El registro de la conversación siempre refleja el contexto que el agente recibió realmente.
Próximos pasos
Lee Agregar campos de contexto para conocer el ciclo de vida completo del registro de Campo de contexto, o vuelve a Optimizador de campos de contexto para obtener recomendaciones asistidas por IA.