Résoudre les problèmes de configuration courants avec la création automatique d’enregistrements et les règles de mise à jour
Cet article fournit des résolutions pour les scénarios d’échec de configuration courants avec des règles de création et de mise à jour automatiques d’enregistrement, en raison de laquelle la création d’enregistrements peut échouer ou être ignorée.
Scénario 1
Exemple : Configuration sur la création et la règle de mise à jour automatiques d’enregistrements
- L’option Créer un contact pour l’expéditeur inconnu doit être sélectionnée.
- Définissez les critères de condition sur Tous les messages électroniques entrants.
- 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 cas est manquant pour le client »
Dans le champ Client de la section CASE DETAILS , la valeur du compte d’expéditeurs (e-mail) est définie comme indiqué ci-dessous.
Ce paramètre génère l’erreur suivante dans les travaux système :
Le cas est manquant pour le client.
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 génère l’erreur suivante dans les travaux système :
Une erreur s’est produite. Réessayez cette action. Si le problème persiste, consultez le Communauté Dynamics 365 Microsoft pour obtenir des solutions ou contactez l’administrateur Microsoft Dynamics 365 de votre organisation. 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é qui a été spécifié dans le champ client ».
Les champs Client et Contact sont définis comme {Sender(Email)}.
Ce paramètre génère l’erreur suivante dans les travaux système :
Le contact spécifié n’appartient pas au contact 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 principale du problème et la résoudre.
| Option dans la gestion de services des Règles de mise à jour et de création d’enregistrements automatiques | Si sélectionnée comme | Étapes de validation | Résultat |
|---|---|---|---|
| Créer un incident s’il existe un droit valide pour le client | Oui | Valider qu’un droit actif existe pour le client. Le droit actif valide est évalué comme indiqué ci-dessous : - Si l’expéditeur de l’e-mail est un contact avec un compte parent, Dynamics 365 Customer Service crée un cas si le compte parent du contact a un droit valide, et que le contact est répertorié dans la section Contacts du droit d’utilisation 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 incident pour un courrier électronique provenant d’expéditeurs inconnus | Oui | Pour tous les courriers électroniques entrants provenant d’un expéditeur inconnu | - Un cas est créé. - Un contact est également créé pour l’expéditeur inconnu. |
| Oui | Pour un courrier électronique entrant avec l’adresse de messagerie d’un compte ou d’un contact inactif | - Un cas est créé. - Un compte ou contact inactif est activé. |
|
| Non | Pour un courrier électronique entrant avec l’adresse de messagerie d’un compte ou d’un contact actif | Un cas est créé. | |
| Non | Pour un courrier électronique entrant envoyé par un type d’enregistrement autre qu’un compte ou un contact | Aucun cas n’est créé. | |
| Non | Pour un courrier électronique entrant avec l’adresse de messagerie d’un compte ou d’un contact inactif | Aucun cas n’est créé. | |
| Créer un incident pour les activités associées à un incident résolu | Oui | Pour un courrier électronique entrant relatif à un incident résolu | Un cas est créé. |
| Oui | Pour un courrier électronique entrant relatif à un incident 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 hérités de « création et de mise à jour des règles d’enregistrement automatique » dans Customer Service, pour rechercher l’entité (un contact ou un compte) qui envoie un e-mail, vous pouvez utiliser la recherche polymorphe de l’expéditeur (e-mail), 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 plus qu’un type d’entité. Par exemple, elle peut pointer vers un contact ou un compte. Toutefois, dans les « règles modernes de création et de mise à jour d’enregistrements automatiques », 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 flux de travail hérité, car les expressions de flux référencent une valeur de données à partir de l’une des charges utiles de l’étape de flux précédente. Par exemple, si la valeur {Regarding(Email)} est vide lorsque le flux commence, la valeur dans la charge utile de l’étape du 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 la charge utile dans le flux ne le fait pas. Ainsi, lorsque la valeur de la charge utile est référencée dans les étapes suivantes du flux, 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 l'« ID d’incident » ou « OData Id ». Utilisez l'« ID OData » pour les champs qui nécessitent une référence d’entité ou des recherches. Utilisez l’identificateur unique de casse pour les champs qui nécessitent un GUID.
Scénario 3 - Problèmes liés au rendu de recherches polymorphes sur des champs non-recherche lors de la migration d’un héritage vers des règles modernes de création et de mise à jour d’enregistrements automatiques
Un élément hérité de « création et de mise à jour des règles d’enregistrement automatique » utilisant des recherches polymorphes, telles que l’expéditeur, entraîne une recherche non valide lorsqu’elle est affectée à un champ de texte.
Dans les éléments hérités de « création et de mise à jour des règles d’enregistrement automatique » dans le service clientèle, pour rechercher l’entité (un contact ou un compte) qui a envoyé un e-mail, vous pouvez utiliser la recherche polymorphe de l’expéditeur (e-mail), 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 plus qu’un type d’entité. Par exemple, elle peut pointer vers un contact ou un compte. Toutefois, dans les « règles modernes de création et de mise à jour d’enregistrements automatiques », 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 flux de travail classique utilisé par les règles héritées de création et de mise à jour d’enregistrements a de nombreux comportements masqués. Par exemple, déterminez automatiquement le type d’entité et récupérez un champ comme nom d’affichage si le paramètre est utilisé dans une chaîne, mais retournez l’ID s’il est affecté à un champ de recherche. Le code de migration de la plateforme que « les règles de création et de mise à jour automatiques d’enregistrement » utilise lors de la conversion d’un flux de travail hérité en flux de travail moderne n’ajoute pas les étapes et champs requis.
Résolution
Pour résoudre ce problème,
- Mettez à jour la recherche vers un type spécifique.
- Utilisez un champ différent dans l’entité entrante qui contient le texte souhaité.