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.
Ce paramètre entraîne l’erreur suivante dans les travaux système :
Client manquant dans le cas.
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)}.
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.
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)}.
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.
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é.