🔍Le Lookup Polymorphique dans Dynamics 365 : un champ, plusieurs entités, un monde de possibilités

Dans Dynamics 365, les lookups sont partout.

Ces champs relationnels permettent de créer des liens entre des entités.

Par exemple, relier une opportunité à un compte, ou une tâche à un contact. Mais parfois, le modèle métier impose une souplesse supplémentaire.

Prenons un exemple classique : tu veux rattacher un enregistrement à un “client”, mais ce client peut être soit une société (Compte), soit une personne physique (Contact). Un simple lookup ne suffit plus, car il ne peut référencer qu’une seule entité.
C’est là qu’intervient le lookup polymorphique.

Un autre exemple ? Ton compte peut avoir comme propriétaire un utilisateur ou une équipe.

Qu’est-ce qu’un Lookup Polymorphique ?

Un lookup polymorphique est un champ de type relation N:1 vers plusieurs entités potentielles. Il permet de faire pointer un seul champ vers des entités de types différents.

🔁 Exemples concrets déjà présent dans Dynamics 365

• Le champ Customer dans une opportunité (opportunity.customerid) est un lookup polymorphique : il peut référencer soit un account (compte), soit un contact.

• Autre exemple : Regarding dans une activité (activity.regardingobjectid). Il peut référencer quasiment n’importe quelle entité (lead, case, account, etc.), selon le contexte de l’activité.

Exemple de cas d’usage métiers

1. Application RH : Signalement

Supposons que tu crées une application RH qui permette de signaler des problèmes.

Tu as donc une entité personnalisée “Signalement” : ce signalement peut concerner un produit, un projet ou un collaborateur.

Un lookup classique ne suffira pas.

Le polymorphisme te permet d’avoir un seul champ “ Object du signalement” qui s’adapte dynamiquement.

2. Comptes dans l’industrie

Dans certains cas dans l’industrie, ton compte est géré par un commercial.

Classique et logique. C’est lui ton propriétaire.

Et il arrive aussi que tu as un deuxième propriétaire. Qui lui peut être une administratrice des ventes, voir une équipe, ou un agent externe qui ne fait pas parti de tes utilisateurs !

Comment ça s’affiche dans Dynamics ?

Techniquement, un lookup polymorphique est un champ composite qui stocke :

• un GUID

• le type d’entité cible

{ "customerid": "a234f5fa-8912-4e5b-b3b0-dedf9d73d9c3", "_customerid_type": "contact" }

Dans Power Apps ou Dynamics, l’interface détecte dynamiquement le type pour afficher l’icône, le nom, et permettre les recherches.

Comment créer un lookup polymorphique ?

Prenons comme cas pratique un deuxième propriétaire sur un compte, référençant des utilisateurs et des agents externes

Donc comment créer ce Lookup Polymorphique ?

• Lance XrmToolBox, connecte-toi à ton environnement, et ouvre l’outil Polymorphic Lookup Creator.

• À gauche :

  • Choisis la solution dans laquelle tu veux créer le champ.

  • Choisis la table cible (ici : Compte) c’est à dire l’entité sur laquelle apparaîtra ce nouveau champ.

  • Indique le nom d’affichage et le nom de schéma du champ.

  • Coche les tables que tu veux pouvoir référencer (Utilisateur et Agent dans notre cas).

• À droite :

  • Tu peux consulter les détails de chaque relation générée (et les ajuster si besoin).

• Clique sur Create Polymorphic Lookup en haut à droite.

• ➡️ Et voilà ! Le champ sera visible dans ta solution, et tu pourras l’ajouter à un formulaire.

⚠️ Attention aux subtilités

Voici ce qu’il faut savoir pour éviter les mauvaises surprises :

1. 🧱 Le portail Power Apps est trompeur

Une fois le champ créé, le Maker Portal te montrera le lookup comme s’il était relié uniquement à la première table sélectionnée. Aucune mention du polymorphisme !

👉 Pense à bien documenter ces champs et à communiquer à ton équipe leur nature réelle.

2. 🧩 Risque d’échec lors de l’import de solution

Lors de la création, l’outil ajoute automatiquement les relations et les entités référencées dans ta solution.

Mais attention : si tu n’inclus pas la métadonnée de la table (en cochant “inclure métadonnées” lors de l’ajout à la solution), l’import échouera à cause de dépendances manquantes.

👉 Solution : retire et réintègre proprement les tables concernées avec métadonnées.

3. 🔄 Modification uniquement via XrmToolBox

Tu ne pourras pas modifier les entités référencées dans ce champ via le Maker Portal. Il faudra repasser par l’outil Polymorphic Lookup Creator :

• Ouvre le champ existant

• Ajoute/supprime les tables nécessaires

• Clique sur Apply Changes

🚨 Si tu supprimes une table déjà utilisée dans des données existantes, attention aux références cassées.

4. 🔁 Power Automate : pense au contrôle Switch

Dans Power Automate, tu devras utiliser un Switch sur la propriété _lookupname@Microsoft.Dynamics.CRM.lookuplogicalname pour distinguer les types d’entités avant d'accéder à leurs données.

Limite actuelle : 25 branches. Mais honnêtement… au-delà de 5 entités, c’est déjà difficilement maintenable.

5. 🚫 Pas d’auto-référence

Tu ne peux pas référencer la table d’origine dans le champ

Exemple : un Contact ne peut pas être lié à un autre Contact via un lookup polymorphique sur la table Contact 🤯🤯

Cela provoquerait un conflit logique : la table ne peut être à la fois référente et référencée.

6. 📭 Tables vides invisibles

Si une table référencée ne contient aucun enregistrement, elle n’apparaîtra pas comme option sélectionnable dans l’interface utilisateur (jusqu’à ce qu’elle ait des données).

Conclusion

Le lookup polymorphique dans Dynamics 365 est un excellent outil pour simplifier les modèles de données sans compromettre la flexibilité.

Il est déjà utilisé en standard dans des entités comme activitypointer, opportunity, ou email.

Mais comme toute bonne chose, il faut l’utiliser avec parcimonie : il introduit une complexité dans les requêtes, les flux Power Automate, et les rapports.

Mon conseil : utilise-le quand il simplifie l’expérience utilisateur ou évite une duplication de schéma.

Mais évite-le quand les entités référencées ont des comportements trop différents, ou quand tu prévois une forte utilisation analytique.