Changer un utilisateur de Business Unit sans perdre ses rôles dans Dynamics 365

Dans la vie d’une organisation, il est courant qu’un commercial change de division ou de pays (un VIE par exemple).

👉 Un collaborateur rejoint une nouvelle équipe.
👉 Un portefeuille client est transféré d’une BU à une autre.

Dans Dynamics 365, ce changement se traduit par une modification de la Business Unit (BU) de l’utilisateur.

Mais attention ⚠️ : si vous n’avez pas configuré correctement certains paramètres, cela peut avoir des conséquences.

Le problème

Lorsqu’on change un utilisateur de Business Unit, deux comportements “par défaut” posent souvent problème :

• Suppression des rôles de sécurité

  Dès que l’utilisateur passe dans une autre BU, tous ses rôles sont retirés.

  Résultat : l’utilisateur perd ses accès et ne peut plus travailler.*

• Migration des enregistrements vers la nouvelle BU

  Tous les enregistrements dont l’utilisateur est propriétaire (comptes, opportunités, activités…) changent également de BU.

  Cela peut casser la cohérence de la donnée et vos règles de gouvernance.

Bref, un simple changement administratif peut se transformer en cauchemar opérationnel.

La solution : deux paramètres OrgDBSettings à connaître

Heureusement, Dynamics 365 vous laisse la possibilité d’adapter ce comportement grâce aux OrgDBSettings (voir article sur OrgDBSettings).

1. Ne pas déplacer automatiquement les enregistrements

Le paramètre à modifier est :

Démarquez-vous

Quel que soit le cas, la façon dont vous racontez votre histoire en ligne peut faire toute la différence.

👉 Mettez-le à False.
Ainsi, lorsqu’un commercial change de BU, ses comptes et opportunités restent rattachés à leur BU d’origine.

2. Ne pas supprimer les rôles au changement de BU

Le paramètre à modifier est :

Démarquez-vous

Quel que soit le cas, la façon dont vous racontez votre histoire en ligne peut faire toute la différence.

👉 Mettez-le à True.
De cette façon, l’utilisateur conserve ses rôles de sécurité après le transfert.

Comment appliquer ces paramètres ?

Deux méthodes sont possibles :

• Solution Microsoft : téléchargez et installez la solution OrgDBSettings depuis le site officiel.

• XrmToolBox : utilisez le plugin OrgDBSettings Editor, qui permet de rechercher et modifier facilement les paramètres.

Recommandations pratiques

• Toujours tester en bac à sable avant de modifier un paramètre.

• Documenter les choix : certains DSI préfèrent garder le comportement par défaut (suppression des rôles = sécurité renforcée).

• Communiquer avec les équipes métiers : un changement de BU ne doit pas bloquer la productivité des collaborateurs.

Conclusion

Un changement de Business Unit est un événement courant dans la vie d’une organisation.
Mais dans Dynamics 365, sans configuration adaptée, cela peut conduire à des pertes de rôles et à des déplacements massifs de données.

Heureusement, en ajustant simplement deux paramètres OrgDBSettings :

• AlwaysMoveRecordToOwnerBusinessUnit = False

• DoNotRemoveRolesOnChangeBusinessUnit = True

… vous gardez le contrôle et évitez des tracas à vos équipes.

OrgDBSettings : les paramètres cachés de Dynamics 365

Quand on administre un environnement Dynamics 365, on se rend vite compte qu’il existe des comportements difficiles à expliquer.

👉 Pourquoi le commercial n’a plus accès ses accès lorsqu’on le change de Business Unit ?
👉 Pourquoi des comptes migrent automatiquement d’une division à une autre ?

Souvent, la réponse se trouve dans un endroit magique

Là ou se trouve beaucoup de paramétrage, cet endroit peu connu mais essentiel : OrgDBSettings.

Là où la magie opère

OrgDbSettings

Qu’est-ce qu’OrgDBSettings ?

L’OrgDBSettings (Organization Database Settings) est un ensemble de paramètres systèmes propres à votre organisation Dynamics 365.

Ils permettent de modifier le comportement par défaut de la plateforme.

Ces paramètres couvrent un large éventail de fonctionnalités :

• gestion de la sécurité et des rôles,

• comportement des Business Units,

• performance et timeouts,

• règles de synchronisation,

• et bien d’autres.

En clair : c’est une boîte noire qui contrôle la mécanique fine de Dynamics 365.

Comment y accéder ?

Il existe deux méthodes principales pour consulter et modifier les OrgDBSettings.

1. La solution officielle Microsoft

Voici comment installer OrgDbSettings sur votre environnement Power Platform

• Microsoft met à disposition une solution téléchargeable et installable directement dans votre environnement.
  ➡️ Télécharger la dernière version ici

• Importer là dans votre environnement Power Apps

• Retrouver la solution Organization Settings Editors (Dynamics 365) dans les solutions managées

• Cliquer sur la solution, dans les … aller sur "Switch to classic”

• Et voilà !

Solution Téléchargeable

On télécharge la solution en cliquant sur le .zip qui se termine en _managed

Go Power Apps et on importe la solution

Un droit d’administrateur Dynamics Power Platform est nécessaire pour y avoir accès

La solution importée, on l’ouvre

On clique simplement sur la solution

Et Switch to classic

Cela permettra d’accèder à l’outil de paramètrage

OrgDbSettings

Et voilà !

Une fois installée, vous pouvez consulter et modifier les paramètres depuis l’interface du CRM, sans outil externe.

Avantages :

• support officiel Microsoft,

• interface intégrée à Dynamics 365,

• pas besoin d’outil tiers.

Inconvénients :

• mise à jour de la solution nécessaire,

• interface un peu “brute” pour naviguer entre les paramètres.

2. L’éditeur OrgDBSettings dans XrmToolBox

Si vous êtes administrateur ou consultant, vous connaissez sûrement XrmToolBox, la boîte à outils indispensable pour Dynamics 365 et Dataverse.
Bonne nouvelle : il existe un plugin dédié appelé OrgDBSettings Editor.

Fonctionnalités :

• recherche rapide d’un paramètre,

• explications intégrées,

• modification en un clic,

• sauvegarde et documentation facilitée.

Avantages :

• interface claire et rapide,

• pas besoin d’installer de solution dans l’environnement,

• parfait pour gérer plusieurs organisations en parallèle.

Cas d’usage : pourquoi c’est utile ?

Prenons quelques exemples concrets :

• Empêcher la suppression automatique des rôles d’un utilisateur lors d’un changement de BU.

• Éviter que les enregistrements (comptes, opportunités) changent automatiquement de Business Unit avec leur propriétaire.

• Ajuster des comportements de synchronisation Outlook.

• Modifier des délais techniques (timeouts).

En résumé : l’OrgDBSettings permet d’adapter Dynamics 365 à vos règles métier et de gouvernance, sans personnalisation lourde.

🔒 Dynamics 365 – Comment filtrer les utilisateurs visibles dans un Lookup

Dans Dynamics 365, le champ Lookup vers la table Utilisateur (systemuser) est partout : attribution d’un enregistrement, responsable d’un compte, commercial en charge, etc.

Mais il souffre souvent d’un problème de pollution : tous les utilisateurs actifs s’y affichent, y compris ceux sans licence CRM, ou même des comptes techniques comme #ADSync.

👉 Dans cet article, je t’explique pourquoi c’est problématique, comment fonctionne réellement la table des utilisateurs, et surtout comment personnaliser proprement le Lookup pour n’afficher que les vrai humains.

🎯 Problématique : un champ Lookup… trop bavard

Par défaut, un champ Lookup vers la table Utilisateur (systemuser) affiche tous les utilisateurs actifs. Cela comprend :

• Des utilisateurs sans licence CRM (donc inutilisables dans la pratique),

• Des comptes synchronisés automatiquement depuis Azure AD (#ADSync, #EXT#, etc.),

• Et parfois des comptes techniques utilisés pour l’intégration ou les flux d’automatisation.

Résultat :

• Le champ est difficile à lire.

• Le risque d’erreur (attribution à un mauvais compte) est réel.

• L’expérience utilisateur est dégradée.

🧠 Mieux comprendre la table systemuser

La table Utilisateur contient tous les utilisateurs ayant été créés dans ton environnement CRM.

Mais tous ne sont pas égaux. Voici les trois grandes familles d’utilisateurs que tu peux y retrouver :

1. 👤 Les utilisateurs métier avec licence CRM

Ils ont un rôle de sécurité, une licence Dynamics, et utilisent activement le CRM. Ce sont eux que tu veux voir dans le Lookup.

2. 🛠 Les comptes techniques (#ADSync, #EXT#, etc.)

Ils sont souvent créés automatiquement par une synchronisation Azure AD (AAD Connect).

Leur nom contient un #, parfois en préfixe.

Ils n'ont pas vocation à être sélectionnés par les utilisateurs.

3. 🧟 Les utilisateurs sans licence

Certains comptes n’ont pas (ou plus) de licence CRM.

Ceux sont tes anciens collègues partis de l’entreprise par exemple

Ils peuvent être actifs dans Azure AD mais n'ont aucun accès à Dynamics. Pourtant, ils s'affichent quand même dans le Lookup.

📋 Identifier les utilisateurs "licenciés"

Le champ clé ici s’appelle “Utilisateur avec Licence” . C’est lui qui te permet de filtrer proprement les utilisateurs CRM.

👉 Il suffit donc de filtrer sur “Utilisateur avec Licence “pour ne garder que les utilisateurs réellement actifs et licenciés.

🛠 Mise en œuvre

✅ 1.Ajouter la bonne vue dans la solution

Il existe d’innombrables vues dans le CRM

Celle pour la recherche d’utilisateur s’appelle…Vue Recherche d’utilisateurs 😊

✅ 2. Ajouter le bon filtre dans la vue

On ouvre la vue dans Power Apps > Edit Filter

Et on rajoute

• Utilisateur avec licence égal à Oui

✅ 3. On enregistre et on publie…

Ou Save and Publish, ça depend de la langue de ton Power Apps

💡 Pourquoi c’est important

👉 Afficher trop d’utilisateurs dans un Lookup, c’est exposer l’utilisateur à l’erreur.

✔️ En filtrant proprement :

• Tu améliores l’expérience utilisateur,

• Tu limites les erreurs d’attribution,

• Tu professionnalises l’usage du CRM.

✍️ Conclusion

Un bon CRM ne montre que ce qui est utile.

En filtrant tes champs Lookup, tu rends le CRM plus clair, plus propre, plus efficace.

Et ça, tes utilisateurs te le rendront.

🔍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.