Résoudre les problèmes de configuration courants liés aux règles de création et de mise à jour automatiques d’enregistrements

Cet article fournit des solutions pour les scénarios d’échec de configuration courants avec des règles de création et de mise à jour automatiques d’enregistrements, en raison de laquelle la création d’enregistrements peut échouer ou être ignoré.

Scénario 1

Exemple : Configuration de la règle de création et de mise à jour automatiques d’enregistrements

  • L’option Créer un contact pour un expéditeur inconnu doit être sélectionnée.
  • Définissez critères de condition sur N’importe quel e-mail entrant.
  • Ajoutez une action pour créer un cas, sélectionnez Afficher les propriétés et définissez les champs de cas par cas d’usage professionnel.

Erreur 1 : « Le client est manquant »

Dans le champ Client de la section DÉTAILS DE LA CASSE, la valeur de Compte d’expéditeur (Email) est définie comme indiqué ci-dessous.

Capture d’écran montrant comment la valeur du compte d’expéditeur (Email) est définie dans le champ Client.

Ce paramètre entraîne l’erreur suivante dans les travaux système :

Client manquant dans le cas.

Capture d’écran montrant les détails de l’erreur indiquant que le client est manquant.

Résolution de l’erreur 1

Pour résoudre ce problème, conservez le champ Client vide ou définissez-le sur {Sender(Email)}. Cela permet au système de créer automatiquement un contact pour l’expéditeur inconnu et de le lier au cas.

Erreur 2 : « Une erreur s’est produite »

Le champ Client est défini sur {Senders Account(Email)}, et le champ Contact est défini sur {Sender(Email)}.

Capture d’écran montrant les valeurs définies pour les champs Client et Contact.

Ce paramètre entraîne l’erreur suivante dans les travaux système :

Une erreur s’est produite. Réessayez cette action. Si le problème persiste, case activée microsoft Dynamics 365 Community pour obtenir des solutions ou contactez l’administrateur Microsoft Dynamics 365 de votre organization. Enfin, vous pouvez contacter Support Microsoft.

Capture d’écran montrant les détails de l’erreur qui se produit en raison de la valeur définie pour le champ Client.

Résolution de l’erreur 2

Pour résoudre ce problème, conservez le champ Client vide ou définissez-le sur {Sender(Email)}. Cela permet au système de créer automatiquement un contact pour l’expéditeur inconnu et de le lier au cas.

Erreur 3 : « Le contact spécifié n’appartient pas au contact spécifié dans le champ client . »

Les champs Client et Contact sont définis comme {Sender(Email)}.

Capture d’écran montrant la valeur définie pour les champs Client et Contact.

Ce paramètre entraîne l’erreur suivante dans les travaux système :

Le contact spécifié n’appartient pas au contact qui a été spécifié dans le champ client. Supprimez la valeur du champ de contact ou sélectionnez un contact associé au client sélectionné, puis réessayez.

Capture d’écran montrant les détails de l’erreur indiquant que le contact spécifié n’appartient pas au contact spécifié dans le champ Client.

Résolution de l’erreur 3

Pour résoudre ce problème, laissez le champ Contact vide et définissez le champ Client sur vide ou sur {Sender(Email)}.

Étapes de validation

Vous devez valider les étapes de configuration et de validation fournies dans le tableau suivant pour comprendre la cause main du problème et le résoudre.

Option dans la règle de création et de mise à jour automatiques d’enregistrements dans la gestion des services S’il est sélectionné comme Étapes de validation Résultat
Créer un cas s’il existe un droit valide pour le client Oui Vérifiez qu’il existe un droit actif pour le client. Le droit actif valide est évalué comme suit :
- Si l’expéditeur de l’e-mail est un contact avec un compte parent, Dynamics 365 service clientèle crée un cas si le compte parent du contact dispose d’un droit valide et que le contact est répertorié dans la section Contacts du droit
ou ,
- Si la section Contacts est vide (ce qui signifie que le droit est applicable à tous les contacts pour le client)
Un cas est créé.
Créer un cas à partir d’un e-mail envoyé par des expéditeurs inconnus Oui Pour tout e-mail entrant provenant d’un expéditeur inconnu - Un cas est créé.
- Un contact est également créé pour l’expéditeur inconnu.
Oui Pour un e-mail entrant avec l’adresse e-mail d’un compte ou d’un contact inactif - Un cas est créé.
- Un compte ou un contact inactif est activé.
Non Pour un e-mail entrant avec l’adresse e-mail du compte ou du contact actif Un cas est créé.
Non Pour un e-mail entrant envoyé par un type d’enregistrement autre que compte ou contact Aucun cas n’est créé.
Non Pour un e-mail entrant avec l’adresse e-mail d’un compte ou d’un contact inactif Aucun cas n’est créé.
Créer un cas pour les activités associées à un cas résolu Oui Pour un e-mail entrant lié à un cas résolu Un cas est créé.
Oui Pour un e-mail entrant lié à un cas actif Aucun cas n’est créé.

Scénario 2 - L’utilisation de {Regarding(Email)} dans l’expérience héritée ne donne pas les données correctes dans le flux

Dans les éléments « règles de création et de mise à jour automatiques des enregistrements » hérités dans Customer Service, pour rechercher l’entité (un contact ou un compte) qui envoie un e-mail, vous pouvez utiliser la recherche polymorphe Expéditeur (Email), qui extrait automatiquement l’entité appropriée et affiche le nom de l’entité. Les recherches polymorphes sont des recherches où la cible de la recherche est plusieurs types d’entité. Par exemple, il peut pointer vers un contact ou un compte. Toutefois, dans les « règles de création et de mise à jour automatiques d’enregistrements » modernes, cet affichage automatique n’est pas pris en charge. Vous devez donc spécifier le type d’entité que vous souhaitez récupérer avec les champs à afficher à partir de cette entité.

Cause

Un flux n’utilise pas la valeur {Regarding(Email)} comme un workflow hérité, car les expressions de flux font référence à une valeur de données de l’une des charges utiles de l’étape de flux précédente. Par exemple, si la valeur {Regarding(Email)} est vide au début du flux, la valeur de la charge utile de l’étape de déclencheur pour {Regarding(Email)} reste vide. Même si la valeur {Regarding(Email)} est mise à jour après la création d’un cas, les données d’enregistrement d’e-mail sont mises à jour, mais pas la charge utile dans le flux. Par conséquent, lorsque la valeur de la charge utile est référencée dans les étapes de flux suivantes, elle reste vide.

Résolution

Si la valeur {Regarding(Email)} est utilisée dans les éléments de règle hérités, vous devez mettre à jour manuellement le flux migré pour utiliser « Id d’incident » ou « ID OData ». Utilisez l'« ID OData » pour les champs qui nécessitent une référence d’entité ou des recherches. Utilisez l’identificateur cas unique pour les champs qui nécessitent un GUID.

Scénario 3 - Problèmes liés au rendu des recherches polymorphes sur des champs sans recherche lors de la migration de règles de création et de mise à jour automatiques d’enregistrements héritées vers modernes

Un élément hérité « règles de création et de mise à jour automatiques d’enregistrements » utilisant des recherches polymorphes, telles que Sender, entraîne une recherche non valide lorsqu’elle est affectée à un champ de texte.

Dans les éléments hérités « règles de création et de mise à jour automatiques d’enregistrements » dans Customer Service, pour rechercher l’entité (un contact ou un compte) qui a envoyé un e-mail, vous pouvez utiliser la recherche polymorphe expéditeur (Email), qui extrait automatiquement l’entité appropriée et affiche le nom de l’entité. Les recherches polymorphes sont des recherches où la cible de la recherche est plusieurs types d’entité. Par exemple, il peut pointer vers un contact ou un compte. Toutefois, dans les « règles de création et de mise à jour automatiques d’enregistrements » modernes, cet affichage automatique n’est pas pris en charge. Par conséquent, vous devez spécifier le type d’entité que vous souhaitez récupérer, ainsi que les champs à afficher à partir de cette entité.

Cause

Le comportement de workflow classique utilisé par les « règles de création et de mise à jour automatiques d’enregistrements » héritées présente de nombreux comportements masqués. Par exemple, déterminer automatiquement le type d’entité et extraire un champ comme nom d’affichage si le paramètre est utilisé dans une chaîne, mais renvoyer l’ID s’il est affecté à un champ de recherche. Le code de migration de plateforme utilisé par les « règles de création et de mise à jour automatiques des enregistrements » lors de la conversion de workflows hérités en flux de travail modernes n’ajoute pas les étapes et les champs requis.

Résolution

Pour résoudre ce problème,

  • Mettez à jour la recherche vers un type spécifique.
  • Utilisez un autre champ sur l’entité entrante qui contient le texte souhaité.