Relations polymorphes
Task.WhoId, Task.WhatId, Event.WhoId et Event.WhatId. REDA AI les gère dans le contexte d’enregistrement et propose un paramètre par agent pour déterminer le niveau de rigueur lorsque certains éléments ne peuvent pas être résolus.Pourquoi est-ce important ?
La plupart des champs de relation ciblent un seul objet : Account.OwnerId pointe toujours vers un utilisateur. Salesforce propose aussi plusieurs relations polymorphes, dont la cible dépend de l’enregistrement :
| Champ | Cibles possibles |
|---|---|
Task.WhoId |
Contact, Lead |
Task.WhatId |
Account, Opportunity, Case, Campaign, Contract et plusieurs autres objets |
Event.WhoId |
Contact, Lead |
Event.WhatId |
Account, Opportunity, Case et d’autres objets associés |
FeedItem.ParentId |
Tout objet disposant d’un fil |
Le traitement dépend des types de cibles exposés par les métadonnées de relation. REDA AI n’ajoute pas automatiquement le champ de nom lorsqu’une relation peut cibler plusieurs objets : ces objets ne possèdent pas nécessairement le même champ d’identification.
Comment REDA AI les traite
Lorsque la plateforme prépare le contexte d’enregistrement, elle charge les noms de champs configurés et, si Inclure les noms apparentés est activé, ajoute automatiquement le nom de l’enregistrement associé à chaque relation compatible. L’ajout de Relationship.Name, ou du champ de nom propre à l’objet cible, suit une règle unique :
La plateforme ajoute automatiquement Relationship.Name uniquement pour les relations ciblant un seul objet. Les relations polymorphes, à plusieurs cibles, sont ignorées pour cet ajout : leur identifiant est inclus, mais pas leur nom.
Cette protection est volontaire. Une référence construite aveuglément telle que WhoId.Name ne constitue pas une méthode générale fiable pour résoudre ces relations. REDA AI limite l’ajout automatique aux relations dont il peut identifier un seul objet cible et son champ de nom.
Ce que l’agent reçoit
- Pour les relations non polymorphes : l’agent reçoit l’identifiant et le nom, par exemple OwnerId: 005… et Owner Name: Jane Smith.
- Pour les relations polymorphes : l’agent reçoit l’identifiant, mais pas le nom. Si ce dernier est nécessaire, il peut le rechercher à la demande avec un outil intégré tel que
get_record.
Pour les modèles métier centrés sur les tâches ou événements, l’agent reçoit donc les données de l’activité, mais doit effectuer une étape supplémentaire pour connaître le nom du contact, de la piste ou de l’enregistrement associé. Cela nécessite un appel d’outil, tout en conservant un comportement d’exécution prévisible.
Mode strict et mode dégradé
En plus de la protection des relations polymorphes, un paramètre propre à l’agent détermine le comportement lorsque certains champs de contexte ne peuvent pas être chargés. Son libellé français est actuellement tronqué : « Autoriser le contexte d'enregistrement d » ; il correspond à Allow Degraded Record Context, qui autorise le contexte dégradé.
| Paramètre | Emplacement | Valeur par défaut |
|---|---|---|
| Autoriser le contexte d'enregistrement d | Dans la définition de l’agent | Désactivé, mode strict |
Mode strict, par défaut
Lorsque l’option est désactivée, tous les champs de contexte configurés doivent pouvoir être chargés. Si un champ a été supprimé, renommé ou rendu inaccessible par la sécurité au niveau des champs (FLS) pour l’utilisateur d’exécution, la plateforme interrompt l’agent avec une erreur. Ce choix convient aux agents internes qui ont besoin d’un contexte cohérent pour prendre des décisions : la conversation s’arrête immédiatement plutôt que de produire une réponse à partir d’informations partielles.
Un second cas, plus courant, déclenche aussi ce paramètre : l’absence de configuration. Si un agent est utilisé sur un objet qui ne possède aucun enregistrement de champ de contexte actif, le mode strict interrompt l’exécution avec le message suivant :
« No active Context Field configuration found for <Object>. Configure a REDAAI_Context_Field__c record or enable Allow Degraded Record Context on the agent. »
Ce message signifie qu’aucune configuration active n’a été trouvée pour l’objet. C’est la cause habituelle de l’échec d’un nouvel agent sur un objet encore non configuré, puisque le mode strict s’applique par défaut. Si l’option est activée, REDA AI utilise plutôt une liste de champs prédéfinie : StageName, Status, Type, Priority, Subject, CloseDate, Amount, Phone, Email, Industry, OwnerId et CreatedDate, avec un plafond de 10 champs pour préserver le fonctionnement des anciens agents. Seuls les champs de cette liste présents sur l’objet sont utilisés ; une véritable configuration reste donc préférable.
Mode dégradé
Lorsque l’option est activée, la plateforme consigne un incident de type avertissement et poursuit avec les champs qu’elle a pu charger. L’agent continue avec un contexte partiel. Ce choix convient aux agents destinés aux clients ou pilotés par API lorsqu’un contexte partiel est acceptable et que certains champs sont volontairement masqués à certains profils.
Trois limites s’appliquent toujours, même en mode dégradé :
- L’enregistrement doit être lisible. Si l’utilisateur d’exécution n’a aucun accès en lecture à l’enregistrement, l’exécution s’arrête.
- L’objet doit être accessible. Un refus d’accès CRUD au niveau de l’objet ne peut pas être contourné par le mode dégradé.
- Au moins un champ configuré doit être accessible. Si tous les champs configurés sont introuvables ou bloqués par la FLS, l’exécution s’arrête même en mode dégradé.
Choisir le mode adapté
| Utilisez le mode strict, option désactivée, lorsque… | Utilisez le mode dégradé, option activée, lorsque… |
|---|---|
| L’agent prend des décisions importantes et doit disposer d’un contexte complet. | Certains utilisateurs ont des restrictions FLS dont l’agent doit tolérer les effets. |
| Vous souhaitez que les erreurs soient visibles et immédiates pendant les tests. | L’agent fonctionne sur des canaux destinés aux clients ou par API, où une poursuite avec un contexte partiel est préférable à une erreur bloquante. |
| Les champs configurés sont stables et vous maîtrisez le schéma. | Le même agent est utilisé par de nombreux profils ayant des droits d’accès différents. |
Vous pouvez modifier ce paramètre à tout moment dans la définition de l’agent. Il prend effet dès la conversation suivante.
Autres relations à plusieurs cibles
Si les métadonnées d’un champ de votre organisation exposent plusieurs cibles Reference To, la même règle s’applique : le nom associé n’est pas ajouté automatiquement. Traitez ces champs comme les relations polymorphes standard :
- Incluez l’identifiant de relation dans la liste si l’agent doit savoir quel enregistrement est référencé.
- Ne supposez pas que Relationship.Name sera ajouté automatiquement.
- Si l’agent a régulièrement besoin du nom associé, donnez-lui un outil qui résout l’identifiant en nom à la demande.
Configurer des agents centrés sur les activités
Les agents qui travaillent principalement sur les tâches ou événements peuvent toujours utiliser ces enregistrements comme contexte. La limitation polymorphe concerne uniquement l’ajout automatique du nom de WhoId et WhatId, pas les autres données de l’enregistrement. Quelques approches utiles :
Configurez l’identifiant et résolvez le type au besoin. Ajoutez le champ direct WhoId ou WhatId au contexte. Les chemins Who.Type et What.Type ne sont pas acceptés dans cette liste de champs directs. Si le type est nécessaire, fournissez à l’agent un outil de requête ou Apex capable de résoudre l’identifiant.
Limitez la cible lorsque c’est possible. Si l’agent s’intéresse uniquement aux tâches associées à des contacts, filtrez à la source, par exemple en utilisant des champs de contexte sur l’objet parent plutôt que sur la tâche.
Utilisez un outil Apex dédié à la résolution. Un outil de classe Apex qui reçoit un identifiant polymorphe et renvoie le nom et le type permet une résolution à la demande sans alourdir le contexte.
Bonnes pratiques
Tenez compte de la protection. La règle de cible unique évite des erreurs intermittentes à l’exécution. Ajouter manuellement un champ de relation à la liste ne modifie pas cette règle d’ajout automatique du nom.
Privilégiez le mode strict par défaut. Le débogage est généralement plus simple lorsque les champs manquants provoquent une erreur explicite. Activez le mode dégradé de manière réfléchie, pour les canaux et profils dont vous comprenez les restrictions.
Examinez le contexte dans le débogueur de conversations. Il affiche exactement les données reçues par l’agent. Si l’agent ignore à qui une tâche se rapporte, consultez d’abord le débogueur : l’identifiant est probablement présent, mais le nom a volontairement été omis.
Fournissez le type par un outil adapté. Les relations Who.Type et What.Type peuvent servir dans une requête SOQL compatible, mais ne sont pas des noms API de champs directs à saisir dans le contexte. Vérifiez le résultat de l’outil pour que l’agent puisse déterminer la prochaine étape.
Questions fréquentes
Non. REDA AI réserve l’ajout automatique du nom aux relations qui ont un seul objet cible. Si l’agent a besoin du nom d’une relation polymorphe, il doit appeler un outil pour le résoudre à la demande.
Oui, lorsqu’ils correspondent à l’objectif de l’agent. La recommandation inclut l’identifiant de relation, sans modifier le comportement à l’exécution : l’ajout automatique du nom reste limité aux relations à cible unique.
En mode strict, l’exécution s’arrête avec une erreur. En mode dégradé, la plateforme consigne un avertissement, retire le champ inaccessible et continue. La transcription reflète les données réellement reçues par l’agent.
Ce paramètre couvre aussi les champs supprimés ou renommés depuis la configuration. Le traitement des relations polymorphes est une protection distincte, appliquée dans les deux modes ; ce paramètre ne la modifie pas.
Oui, c’est l’approche recommandée. L’outil intégré get_record peut récupérer l’enregistrement complet à partir d’un identifiant connu, y compris son nom. Vous pouvez aussi fournir un outil de classe Apex dédié qui reçoit un identifiant polymorphe et un type cible, puis renvoie le nom.
Oui. En mode strict, l’interruption produit une entrée dans le journal des incidents. En mode dégradé, chaque événement de champ manquant produit un incident d’avertissement. L’enregistrement de la conversation reflète toujours le contexte réellement reçu par l’agent.
Prochaines étapes
Consultez Ajouter des champs de contexte pour connaître leur cycle de vie, ou revenez à l’optimiseur de champs de contexte pour obtenir des recommandations de l’IA.