Ces deux étapes créent ensemble l'identité technique que le module DQE Standalone (Unify) utilise pour communiquer automatiquement avec Dynamics 365, sans qu'un utilisateur humain ne se connecte.
Azure App Registration
Le module Standalone ne se connecte pas à Dynamics via un compte utilisateur classique — il s'authentifie en tant qu'application Azure AD. L'enregistrement de cette application dans votre tenant Azure produit trois valeurs nécessaires pour la suite de la configuration : l'Application (client) ID, le Directory (tenant) ID, et un Client Secret. Sans cet enregistrement, il n'existe aucune identité que Dynamics puisse reconnaître comme provenant de l'application Standalone — c'est le composant d'authentification côté Azure.
Dynamics Application User (S2S)
Un enregistrement d'application Azure seul ne donne pas accès aux données Dynamics. Un utilisateur applicatif serveur à serveur (S2S) non interactif doit également être créé à l'intérieur de Dynamics, lié à cette même application Azure (via son Client ID), et se voir attribuer les rôles de sécurité DQE — en particulier DQE – Unify Application User, qui accorde un accès en lecture/écriture aux entités Account, Contact, Lead et DQE, y compris le privilège Merge. C'est ce qui transforme l'identité Azure en un compte disposant réellement de permissions dans l'environnement Dynamics.
En résumé : l'Azure App Registration crée l'identité (qui se connecte), et le Dynamics Application User lui accorde l'accès (ce qu'il peut faire dans Dynamics). Les deux sont nécessaires car l'application Standalone doit lire et écrire les données Dynamics de manière programmatique. Les identifiants générés lors de l'enregistrement Azure sont également réutilisés lors de la création de l'utilisateur applicatif et lors de la configuration de l'identifiant Dynamics au sein de l'application Standalone elle-même.
Associé à