Leads trop anciens : comment assainir votre pipeline commercial avec Power Automate

Introduction

Un lead commercial n’a pas une durée de vie infinie.

Passé un certain délai sans interaction, il cesse d’être une opportunité et devient une donnée morte

Elle pollue votre CRM, fausse vos indicateurs et ralentit vos équipes commerciales.

Dans de nombreuses entreprises, des leads restent ouverts pendant des semaines, voire des mois, sans action réelle.

Ils continuent pourtant d’apparaître dans le pipeline, donnant une illusion de volume et de performance.

👉 Résultat :

• des prévisions commerciales biaisées,

• des décisions prises sur des chiffres inexacts,

• et une perte de temps significative pour les équipes terrain.

La question n’est donc pas combien de leads vous avez, mais combien de leads sont réellement exploitables.

---

Quelle est la durée de vie réelle d’un lead commercial ?

La valeur d’un lead est fortement liée au temps de réaction après sa création.

Plus l’entreprise tarde à entrer en contact, plus l’intérêt du prospect diminue.

Le concept de Speed to Lead est largement documenté dans les médias et études marketing français.

Selon une analyse relayée par FrenchWeb, les entreprises qui contactent un lead rapidement — idéalement dans l’heure — augmentent significativement leurs chances de qualification et de conversion .

À l’inverse, la réalité du marché est souvent bien différente. Une étude citée par Call of Success montre que le délai moyen de réponse aux leads en France atteint environ 47 heures, soit presque deux jours après la première manifestation d’intérêt du prospect .

Autrement dit, lorsque de nombreuses équipes commerciales reprennent contact, le prospect a déjà perdu son intérêt… ou a choisi un concurrent.

---

Quand un lead commence à devenir un problème business

D’un point de vue opérationnel, on peut distinguer plusieurs phases dans la vie d’un lead :

• Moins d’1 heure : le lead est chaud, l’intérêt est maximal.

• Moins de 24 heures : le lead reste qualifiable, mais la probabilité de conversion commence déjà à diminuer.

• Entre 24 et 72 heures : le lead devient froid, la relance est plus difficile et moins efficace.

• Au-delà de quelques jours sans interaction : le lead n’est plus une opportunité active, mais une donnée obsolète.

Ces leads anciens continuent pourtant d’exister dans le CRM.

Ils gonflent artificiellement le pipe, masquent les véritables priorités commerciales et donnent une vision déformée de la réalité.

Comme le souligne FrenchWeb, la réactivité commerciale est un facteur clé de performance, et chaque heure perdue réduit la valeur du lead .

---

Pourquoi les leads trop anciens faussent votre pipeline commercial

Un pipeline encombré de leads obsolètes a des conséquences très concrètes :

• Prévisions commerciales peu fiables
  Les volumes semblent élevés, mais le taux de transformation réel chute.

• Mauvaise allocation du temps commercial
  Les équipes passent du temps sur des prospects qui ne sont plus engagés.

• Tensions entre Marketing et Ventes
  Le marketing génère des leads, les ventes n’y croient plus.

• Décisions stratégiques biaisées
  Les arbitrages sont faits sur des données qui ne reflètent plus le marché.

Un CRM n’est pas censé rassurer. Il est censé dire la vérité.

---

Disqualifier un lead n’est pas un échec, c’est une décision de pilotage

Beaucoup d’organisations hésitent à disqualifier des leads par peur de “perdre” des opportunités.

En réalité, conserver des leads trop anciens revient à mentir à ses propres indicateurs.

Disqualifier un lead permet de :

• clarifier le pipeline,

• assainir les tableaux de bord,

• concentrer les équipes sur les prospects réellement actifs,

• et poser une définition claire et partagée de ce qu’est un lead qualifié.

La durée de vie d’un lead est courte par nature : sans action rapide, il perd mécaniquement de sa valeur

---

Pourquoi l’automatisation devient indispensable

Lorsque la disqualification repose uniquement sur des actions manuelles, elle devient :

• inconstante,

• subjective,

• dépendante des habitudes individuelles.

Automatiser la disqualification des leads trop anciens permet au contraire de mettre en place une règle de gouvernance claire, partagée et mesurable.

Ce n’est pas une optimisation technique, mais une décision de pilotage commercial.

L’automatisation garantit que :

• les règles sont appliquées de manière homogène,

• les données restent cohérentes dans le temps,

• le CRM reflète la réalité du terrain, pas l’historique des oublis

---

Disqualifier les leads avec Power Automate

On va disqualifier les leads avec un Power Automate

• On liste d’abord les leads que l’on souhaite disqualifier

• On applique à chaque lead une modification pour changer son statut et sa raison du statut

On liste les leads

On se concentre ici sur les leads qui n’ont pas été contacté et créé il y a plus d’1 an

• OlderThanXMonths —> pour ceux créés il y a plus de X mois

• OlderThanXWeeks —> pour ceux créés il y a plus de X semaines

• OlderThanXDays —> pour ceux créés il y a plus de X jours

Pour chaque leads, on appel l’action “Mettre à jour une ligne”

Et on met à jour le statut et la raison du statut

Dans notre cas, on exclus le lead et on met comme raison “Temps de réponse trop long” pour pouvoir suivre dans un tableau de bord

Comment ajouter un bouton “Ré-ouvrir une tâche fermée” dans Dynamics 365

Dans Dynamics 365 / Dataverse, lorsque vous fermez une tâche (Task), il n’existe pas nativement de bouton pour la rouvrir dans la barre de commandes.

Cela pose un problème UX concret : les utilisateurs doivent recourir à des workflows manuels ou des outils externes juste pour remettre une tâche en statut ouverte.

Principe

Une tâche repose sur deux colonnes clés :

• statecode → état global (Open / Completed)

• statuscode → raison de statut (Not Started, Completed, Canceled…)

Pour réouvrir une tâche, il suffit de :

• Repasser statecode à Active

• Mettre statuscode sur une valeur cohérente (ex. Not Started)

Choix technique : le nouveau Command Designer

Avec la nouvelle expérience de Command Designer dans le créateur d’app Model-Driven, vous pouvez :

1. Ajouter un bouton dans la barre de commandes

2. Écrire une formule Power Fx pour changer le statut

3. Définir une règle de visibilité pour n’afficher le bouton que sur les tâches complétées

Étape 1 — Ajouter le bouton dans la barre de commandes

Dans votre solution Dynamics 365, ouvrez l’app Model-Driven

1. Allez dans Pages → Task (Tâches) → Modifier la barre de commande

Ajoutez un nouveau bouton puis choisir son

• nom

• icône

• tooltip (info-bulle)

Étape 2 — Réouvrir la tâche au clic

Pour modifier l’état de la tâche et la rouvrir, on utilise Patch() :

Patch(
    Tâches;
    Self.Selected.Item;
    {
       statecode:'Statut d''activité (Tâches)'.Ouvert;
       statuscode:'Raison du statut (Tâches)'.'Non commencé'}
    }
)

statuscode et statecode doivent être alignés : Dataverse gère le statut via ces deux champs combinés, sinon le changement échoue.

Étape 3 — Règle de visibilité

Affichez le bouton seulement si la tâche est fermée (Terminée ou Annulée):

(Self.Selected.Item.'Statut d''activité' = 'Statut d''activité (Tâches)'.Terminé) Or (Self.Selected.Item.'Statut d''activité' = 'Statut d''activité (Tâches)'.Annulé)

Et maintenant plus qu’à publier vos modifications

Et pour aller plus loin vous pouvez

✔ Ajouter une confirmation utilisateur (Notify/Confirm)
✔ Activer les règles de sécurité pour limiter qui peut rouvrir des tâches

Touchdown et Dynamics 365 : Ajouter un Recaptcha Google sur vos formulaires

Nous allons présenter ici comment intégrer un Captcha sur vos formulaires Touchdown.

Les formulaires permettent par exemple de capter les soumissions de vos formulaires de contact et de les intégrer directement en leads dans votre CRM

Sauf que un formulaire de contact sans protection anti-bot, ça va rapidement remplir votre CRM de déchet.

Bonne nouvelle, je vais vous montrer comment corriger ça rapidement.

Objectif

Ajouter Google reCAPTCHA v2 (checkbox) sur un formulaire Touchdown sans casser :

• la validation native Touchdown

• la soumission vers Dynamics 365

• le tracking marketing

Contexte technique

Touchdown génère des formulaires embarqués qui reposent sur :

• un <form> HTML

• un moteur JavaScript interne (tdFormInstance.process())

Impératif absolu : Le formulaire doit être de type “Bloc à intégrer”.

Une fois votre formulaire prêt, récupérer les différents élements.

Ce sont ceux là que l’on va modifier / compléter

Étape 1 : Charger les scripts nécessaires

On va charger les scripts nécessaire en plus de ceux de Touchdown

<script src="https://www.google.com/recaptcha/api.js" async defer></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.7.1/jquery.min.js"></script>

<script type="text/javascript">
  $(document).ready(function () {

    $('#sb_form').submit(function (event) {

      event.preventDefault();

      var response = grecaptcha.getResponse();

      if (response.length == 0) {
        // reCAPTCHA non validé
        $('#alert_captcha').show();
      } else {
        // reCAPTCHA validé
        $('#alert_captcha').hide();
        tdFormInstance.process();
      }

      return false;
    });

  });
</script>

Étape 2 – Ajouter le composant reCAPTCHA dans le HTML

Dans le contenu HTML du formulaire Touchdown, ajoute ce bloc à l’endroit exact où tu veux afficher le captcha (généralement juste avant le bouton Envoyer).

<table width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td style="padding-top: 10px; padding-bottom: 10px;">
      <div class="g-recaptcha" data-sitekey="TA CLE PUBLIQUE GOOGLE"></div>
      <span id="alert_captcha" style="color:red;font-weight:bold;display:none;">
        Vérifier le captcha
      </span>
    </td>
  </tr>
</table>

Étape 3 – Supprimer le onsubmit natif (OBLIGATOIRE)

Par défaut, Touchdown génère un formulaire de ce type :

<form id="sb_form" onsubmit="tdFormInstance.process(); return false;" method="post">

C’est incompatible avec reCAPTCHA

Pourquoi ? Parce que Touchdown intercepte la soumission avant que tu puisses valider le captcha.

<form id="sb_form" method="post">

Et voilà

• ✔️ Le captcha est bloquant

• ✔️ Touchdown reste maître de la soumission

• ✔️ Dynamics 365 reçoit uniquement des leads propres

• ✔️ Aucun impact sur le tracking marketing

Dynamics 365 – Gérer les champs dans les formulaires, entête et BPF en JavaScript

Formulaire, Header et Business Process Flow

Dans Microsoft Dynamics 365, un même champ peut être affiché à plusieurs endroits :

• dans le corps du formulaire

• dans le header

• dans le Business Process Flow (BPF)

👉 Côté métier, l’attente est simple :

“Si le champ devient obligatoire ou masqué, ça doit être cohérent partout.”

👉 Côté technique, la réalité est plus subtile.
Et mal la comprendre conduit à des incohérences UI et des tickets inutiles.

🎯 Cas concret

Champ Dataverse : p365_age

Il est affiché :

• dans le body du formulaire

• dans le header

• dans le BPF

Objectif :

• masquer / afficher le champ

• le rendre obligatoire ou non

• avec un comportement prévisible et maîtrisé

🧠 Principe fondamental

La visibilité est une propriété du contrôle.

L’obligation est une propriété de l’attribut.

🧩 Noms réels des contrôles Dynamics

Pour le champ logique p365_age :

Emplacement : Formulaire —> p365_age

Emplacement : Header—> header_p365_age

Emplacement : BPF —> header_process_p365_age

⚠️ Ces noms sont générés par Dynamics.

🔹 1. Gérer la visibilité (setVisible)

Règle clé

👉 La visibilité se gère au niveau des contrôles

🔹 2. Gérer le caractère obligatoire (setRequiredLevel)

Règle clé

👉 L’obligation est portée par l’attribut, pas par le contrôle

🧪 Cas spécifiques à anticiper

🔹 Le BPF n’est pas chargé

header_process_p365_age peut être null

🔹 Étape BPF inactive

🔹 Exécution trop tôt (OnLoad)

🔹 Utiliser le même Javascript pour un formulaire qui ne possède pas de BPF

Attention dans la réutilisation de vos formulaires.

Un Javascript qui gère l’affiche d’une segmentation dans un BPF sur une opportunité, alors que le BPF n’existe pas dans un formulaire compte vous posera des problèmes.

Augmentation des quotas Dataverse : de 10 Go à 30 Go pour Dynamics 365 & Power Platform (Décembre 2025)

En décembre 2025, Microsoft a révisé à la hausse les quotas de stockage Dataverse inclus par défaut dans les licences Dynamics 365 et Power Platform.

https://admin.cloud.microsoft/?#/MessageCenter/:/messages/MC1181915

MC1181915 - Microsoft Dataverse, Dynamics 365 Apps – Storage capacity and entitlements update

Cette mise à jour, qui a commencé à être appliquée dès le 01 décembre 2025, répond à un besoin clair : les anciennes limites (souvent 5 GB à 10 GB) freinaient la croissance des projets low-code, l’utilisation d’IA, les workflows lourds ou encore la gestion de gros volumes de données.

📈 Les nouveaux quotas Dataverse par type de licence

Voici les changements clés concernant le stockage de base (default database capacity) par produit ou licence :

👉 Pour les clients CRM classiques, le quota passe de 10 GB à 30 GB sans coût additionnel.

📌 Le stockage de fichiers a également été doublé pour la plupart des produits (par exemple, pour Dynamics 365 CRM : de 20 GB à 40 GB).

Par contre, le stockage des logs n’a pas changé.

📌 Comment fonctionne la capacité par défaut

Un point souvent mal compris : le quota de stockage Dataverse “par défaut” ne s’ajoute pas cumulativement à chaque licence :

• Le premier produit qualifiant (Power Apps, Power Automate, Power Pages, Copilot Studio ou une licence Dynamics 365) octroie une capacité par défaut une seule fois par tenant.

• Si tu ajoutes ensuite une licence avec un quota supérieur, le tenant adopte la valeur la plus élevée.

Par exemple : si tu avais Power Apps Per App (15 GB) puis ajoutes une licence Dynamics 365 CRM, ta capacité passe à 30 GB, mais pas à 15 GB + 30 GB.

💡 Impact concret pour les organisations

🚀 1. Plus de liberté

Beaucoup de petites et moyennes organisations atteignaient rapidement le seuil de 10 GB. Avec 30 GB par défaut, les projets CRM durent plus longtemps avant de justifier l’achat de capacité additionnelle (qui reste coûteuse).

💰 2. Moins de pression financière

Avant, atteindre l’un des anciens seuils signifiait acheter des extensions à environ 40 $/GB/mois pour la base de données — un facteur de coût important.

🧠 3. Simplification et anticipation

L’unification du stockage ERP + Dataverse dans un pool unique par tenant facilite la planification de capacité, surtout dans les environnements combinant CRM et ERP.

📊 Comment vérifier si c’est déjà actif chez toi

1. Ouvre le Power Platform Admin Center.

2. Va dans Capacité > Résumé.

3. Tu y verras les quotas mis à jour pour :

   • Database

   • Files

   • Logs

👉 Ces valeurs sont automatiquement appliquées — aucune action manuelle n’est requise.

👉 Ou bien le lien direct : https://admin.powerplatform.microsoft.com/billing/licenses/Dataverse/overview

🧠 Conclusion — quelle est la vraie portée de ce changement

➡️ Cet ajustement représente l’une des plus importantes augmentations des quotas Dataverse depuis des années.

Pour les utilisateurs Dynamics 365 CRM et Power Platform, c’est un vrai coup de pouce pour :

• piloter plus de données,

• déployer davantage d’automatisations et d’apps low-code,

• supporter des scénarios IA plus lourds sans atteindre les limites rapidement.

⚠️ Attention : cela ne rend pas Dataverse illimité, et si ton organisation dépasse ces nouveaux seuils, tu devras toujours acheter des extensions.

Augmentation des prix des licences Microsoft 365 au 01 juillet 2026

📈 Microsoft augmente les prix de Microsoft 365 en 2026

Cette article est publié le 08/12/2025 suite à l’annonce Microsoft du 05/12/2025

Chaque fin d’année, une même dynamique s’installe : les entreprises révisent leurs prévisions financières et finalisent leur budget pour l’année suivante.

Cela va de même pour Microsoft qui annonce une hausse des tarifs de ses offres Microsoft 365 à partir du 1er juillet 2026.

Cette mise à jour tarifaire s'inscrit dans une stratégie plus large :

• intégrer plus de 1 100 nouvelles fonctionnalités, renforcer l’IA (notamment via Copilot),

• améliorer la sécurité et la conformité.

Dans cet article, nous revenons sur les changements annoncés, les produits concernés, et ce que les organisations doivent faire dès maintenant pour limiter l’impact financier.

📆 Quand les nouveaux tarifs entreront-ils en vigueur ?

La date officielle d’application est le 1er juillet 2026.

Tous les renouvellements à partir de cette date utiliseront les nouveaux tarifs.

Pour les entreprises en contrat annuel ou pluriannuel, il faudra vérifier la date de renouvellement : certaines pourront prolonger leurs prix actuels quelques mois de plus, tandis que celles qui renouvellent en Q3/Q4 2026 subiront immédiatement la nouvelle grille.

📦 Quels produits Microsoft 365 voient leur prix augmenter ?

Les hausses ne concernent pas toutes les offres, mais plusieurs SKU clés du marché business, enterprise et frontline.

Tableau récapitulatif des augmentations annoncées

Tableau récapitulatif des augmentations annoncées

➡️ Les offres Frontline (F1/F3) sont les plus impactées proportionnellement.
➡️ Les offres Business Basic / Standard subissent aussi une hausse notable.
➡️ Les offres Premium et certains plans Office restent inchangés.

🔍 Pourquoi cette augmentation des prix ?

Selon Microsoft, l’évolution est liée à plusieurs facteurs structurants :

1. L’intégration massive de l’IA au cœur de Microsoft 365

Copilot, copilots spécialisés, automatisation, analyse contextuelle… Ces capacités transforment la suite bureautique classique en plateforme intelligente.

2. Le renforcement continu de la sécurité cloud

Avec l’explosion des cyberattaques, Microsoft ajoute régulièrement des modules de détection, de prévention et de conformité.

3. Plus de 1 100 fonctionnalités ajoutées en quelques années

Nouvelles expériences Teams, améliorations Outlook, SharePoint Premium, automatisation Power Platform…
Le périmètre fonctionnel a considérablement évolué.

4. Une logique de réalignement avec la valeur perçue

Microsoft ajuste ses prix pour refléter les investissements réalisés — et pour se positionner face à Google Workspace, qui évolue également.

🎯 Ce que doivent faire les entreprises dès maintenant, surtout en pleine saison des budgets 2026

L’information tombe dans un moment critique : la construction des budgets IT 2026.

Pour éviter les mauvaises surprises, plusieurs actions sont recommandées :

1. Réaliser un audit des licences existantes

• Qui utilise quoi réellement ?

• Quels comptes sont inactifs ou surdimensionnés ?

• Quels services Microsoft 365 sont réellement utilisés ?

Un audit permet souvent d'économiser 10 à 25 % sans toucher au confort utilisateur.

2. Adapter les prévisions budgétaires 2026

Intégrer dès maintenant les nouveaux tarifs dans :

• le budget OPEX IT,

• les projections de coûts de croissance,

• les analyses financières multi-sites ou multi-filiales.

3. Optimiser les plans de licences

Exemples :

• passer certaines populations de E3 → Business Premium,

• adopter des licences Frontline mieux adaptées aux usages,

4. Anticiper les renouvellements

Les entreprises qui renouvellent avant juillet 2026 peuvent parfois verrouiller l’ancien tarif jusqu’à 12 mois selon leur contrat et leur mode de facturation.

🧭 Conclusion : une hausse à anticiper, pas à subir

La hausse des tarifs Microsoft 365 du 1er juillet 2026 n’a rien d’anodin, mais elle peut être maîtrisée si les organisations commencent dès maintenant à revoir :

• leur inventaire de licences,

• leur stratégie d’usage,

• leur budget 2026,

• et leurs scénarios de montée en valeur via l’IA.

Les DSI, responsables IT et directions financières ont tout intérêt à intégrer ces nouveaux tarifs dans leur feuille de route.

source : https://www.microsoft.com/en-us/microsoft-365/blog/2025/12/04/advancing-microsoft-365-new-capabilities-and-pricing-update/?msockid=2ea47271146d6ad720b9671415746be0

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.