Häufige Konfigurationsprobleme mit der automatischen Datensatzerstellung beheben und Regeln aktualisieren
Dieser Artikel enthält Lösungen für häufige Konfigurationsfehlerszenarien mit automatischen Datensatzerstellungs- und Aktualisierungsregeln, aufgrund derer die Datensatzerstellung fehlschlägt oder übersprungen wird.
Szenario 1
Beispiel: Konfiguration für die automatische Datensatzerstellung und Aktualisierungsregel
- Die Option "Kontakt für unbekannten Absender erstellen" sollte ausgewählt werden.
- Legen Sie die Bedingungskriterien auf Alle eingehenden E-Mails fest.
- Fügen Sie Eine Aktion zum Erstellen eines Falls hinzu, wählen Sie "Eigenschaften anzeigen" aus, und legen Sie die Fallfelder pro Geschäftsanwendungsfall fest.
Fehler 1 : "Der Fall fehlt kunde"
Im Feld "Kunde" des Abschnitts "FALLDETAILS" wird der Wert des Absenderkontos (E-Mail) wie unten dargestellt festgelegt.
Diese Einstellung führt zu folgendem Fehler in Systemaufträgen:
Der Fall fehlt dem Kunden.
Lösung für Fehler 1
Um dieses Problem zu beheben, behalten Sie das Feld "Kunde " leer, oder legen Sie es auf {Sender(Email)} fest. Auf diese Weise kann das System automatisch einen Kontakt für den unbekannten Absender erstellen und mit dem Fall verknüpfen.
Fehler 2 – "Fehler ist aufgetreten"
Das Feld "Kunde " wird als {Senders Account(Email)} festgelegt, und das Feld "Kontakt " wird als {Absender(E-Mail)} festgelegt.
Diese Einstellung führt zu folgendem Fehler in Systemaufträgen:
Ein Fehler ist aufgetreten. Versuchen Sie es erneut. Wenn das Problem weiterhin besteht, überprüfen Sie die Microsoft Dynamics 365-Community auf Lösungen, oder wenden Sie sich an den Microsoft Dynamics 365-Administrator Ihrer Organisation. Schließlich können Sie sich an Microsoft-Support wenden.
Lösung für Fehler 2
Um dieses Problem zu beheben, behalten Sie das Feld "Kunde " leer, oder legen Sie es auf {Sender(Email)} fest. Auf diese Weise kann das System automatisch einen Kontakt für den unbekannten Absender erstellen und mit dem Fall verknüpfen.
Fehler 3 : "Der angegebene Kontakt gehört nicht zum Kontakt, der im Kundenfeld angegeben wurde."
Die Felder "Kunde " und "Kontakt " werden als {Sender(Email)} festgelegt.
Diese Einstellung führt zu folgendem Fehler in Systemaufträgen:
Der angegebene Kontakt gehört nicht zum Kontakt, der im Kundenfeld angegeben wurde. Entfernen Sie den Wert aus dem Kontaktfeld, oder wählen Sie einen Kontakt aus, der dem ausgewählten Kunden zugeordnet ist, und versuchen Sie es dann erneut.
Lösung für Fehler 3
Um dieses Problem zu beheben, lassen Sie das Feld "Kontakt " leer, und legen Sie das Feld "Kunde " entweder auf "leer" oder auf "{Sender(Email)}" fest.
Überprüfungsschritte
Sie müssen die in der folgenden Tabelle angegebenen Konfigurations- und Überprüfungsschritte überprüfen, um die Hauptursache des Problems zu verstehen und zu beheben.
Option in der automatischen Datensatzerstellungs- und -aktualisierungsregel in der Serviceverwaltung | Wenn ausgewählt als | Überprüfungsschritte | Ergebnis |
---|---|---|---|
Anfrage erstellen, wenn für den Kunden eine gültige Berechtigung vorhanden ist | Ja | Überprüfen, ob eine aktive Berechtigung für den Kunden vorhanden ist Gültige aktive Berechtigung wird wie folgt ausgewertet: - Wenn der Absender der E-Mail ein Kontakt mit einem übergeordneten Konto ist, erstellt der Dynamics 365-Kundendienst einen Fall, wenn das übergeordnete Konto des Kontakts über eine gültige Berechtigung verfügt und der Kontakt im Abschnitt "Kontakte " der Berechtigung "Or" aufgeführt ist– Wenn der Abschnitt "Kontakte " leer ist (was bedeutet, dass die Berechtigung für alle Kontakte für den Kunden gilt) |
Es wird ein Fall erstellt. |
Anfrage aus einer E-Mail erstellen, die von unbekannten Absendern gesendet wurde | Ja | Für alle eingehenden E-Mails von einem unbekannten Absender | - Es wird ein Fall erstellt. – Ein Kontakt wird auch für den unbekannten Absender erstellt. |
Ja | Für eine eingehende E-Mail mit der E-Mail-Adresse einer inaktiven Firma oder eines inaktiven Kontakts | - Es wird ein Fall erstellt. – Ein inaktives Konto oder ein Kontakt wird aktiviert. |
|
No | Für eine eingehende E-Mail mit der E-Mail-Adresse einer aktiven Firma oder eines aktiven Kontakts | Es wird ein Fall erstellt. | |
No | Für eine eingehende E-Mail, die über einen anderen Datensatztyp als eine Firma oder ein Kontakt gesendet wurde | Es wird kein Fall erstellt. | |
No | Für eine eingehende E-Mail mit der E-Mail-Adresse einer inaktiven Firma oder eines inaktiven Kontakts | Es wird kein Fall erstellt. | |
Eine Anfrage für Aktivitäten erstellen, die einer abgeschlossenen Anfrage zugeordnet sind | Ja | Für eine eingehende E-Mail, die mit einer abgeschlossenen Anfrage verknüpft ist | Es wird ein Fall erstellt. |
Ja | Für eine eingehende E-Mail, die mit einer aktiven Anfrage verknüpft ist | Es wird kein Fall erstellt. |
Szenario 2 – Die Verwendung von {Regarding(Email)} in legacy-Erfahrung bietet nicht die richtigen Daten im Fluss.
In älteren Elementen für die automatische Datensatzerstellung und -aktualisierung im Kundendienst können Sie die Entität (entweder einen Kontakt oder ein Konto) suchen, die eine E-Mail sendet, die polymorphe Absendersuche (E-Mail) verwenden, die automatisch die entsprechende Entität abruft und den Namen der Entität anzeigt. Polymorphe Suchen sind Suchvorgänge, bei denen das Suchziel mehr als eine Art von Entität ist. Beispielsweise kann es entweder auf einen Kontakt oder ein Konto verweisen. In modernen Regeln für die automatische Datensatzerstellung und -aktualisierung wird diese automatische Anzeige jedoch nicht unterstützt. Daher müssen Sie den Entitätstyp angeben, den Sie zusammen mit den Feldern angeben möchten, die aus dieser Entität angezeigt werden sollen.
Ursache
Ein Fluss verwendet den Wert "{Regarding(Email)}" nicht wie ein Legacyworkflow, da Flussausdrücke auf einen Datenwert aus einer der Nutzlast des vorherigen Flussschritts verweisen. Wenn beispielsweise der Wert {Regarding(Email)} zu Beginn des Flows leer ist, bleibt der Wert in den Nutzdaten des Triggerschritts für {Regarding(Email)} leer. Auch wenn der Wert "{Regarding(Email)}" nach dem Erstellen eines Falls aktualisiert wird, werden die E-Mail-Datensatzdaten aktualisiert, die Nutzlast im Fluss jedoch nicht. Wenn also in den nachfolgenden Flowschritten auf den Wert aus den Nutzdaten verwiesen wird, bleibt dieser leer.
Lösung
Wenn der Wert "{Regarding(Email)}" in Legacyregelelementen verwendet wird, müssen Sie den migrierten Fluss manuell aktualisieren, um die "Vorfall-ID" oder "OData-ID" zu verwenden. Verwenden Sie die "OData-ID" für Felder, für die Entitätsreferenzen oder -nachschlagevorgänge erforderlich sind. Verwenden Sie den eindeutigen Bezeichner für Felder, für die GUID erforderlich ist.
Szenario 3 – Probleme beim Rendern polymorpher Nachschlagevorgänge für Nicht-Nachschlagefelder während der Migration von legacy zu modernen "automatischen Datensatzerstellungs- und Aktualisierungsregeln"
Ein älteres Element für die automatische Datensatzerstellung und -aktualisierung mithilfe von polymorphen Nachschlagevorgängen, z . B. "Absender", führt zu einem ungültigen Nachschlagevorgang, wenn es einem Textfeld zugewiesen wurde.
In älteren Elementen für die automatische Datensatzerstellung und -aktualisierung im Kundendienst können Sie die Entität (entweder einen Kontakt oder ein Konto), die eine E-Mail gesendet hat, nachschlagen , die polymorphe Suche des Absenders (E-Mail) verwenden, die automatisch die entsprechende Entität abruft und den Namen der Entität anzeigt. Polymorphe Suchen sind Suchvorgänge, bei denen das Suchziel mehr als eine Art von Entität ist. Beispielsweise kann es entweder auf einen Kontakt oder ein Konto verweisen. In modernen Regeln für die automatische Datensatzerstellung und -aktualisierung wird diese automatische Anzeige jedoch nicht unterstützt. Sie müssen also den Typ der Entität angeben, die Sie zusammen mit den Feldern abrufen möchten, die aus dieser Entität angezeigt werden sollen.
Ursache
Das klassische Workflowverhalten, das von älteren "Automatischen Datensatzerstellungs- und Aktualisierungsregeln" verwendet wird, weist viele ausgeblendete Verhaltensweisen auf. Beispielsweise wird automatisch der Typ der Entität bestimmt und ein Feld als Anzeigename abgerufen, wenn der Parameter in einer Zeichenfolge verwendet wird, aber die ID zurückgibt, wenn ein Nachschlagefeld zugewiesen ist. Der Plattformmigrationscode, der bei der Konvertierung von älteren in moderne Workflows "automatische Datensatzerstellungs- und Aktualisierungsregeln" verwendet wird, fügt die erforderlichen Schritte und Felder nicht hinzu.
Lösung
Um dieses Problem zu beheben,
- Aktualisieren Sie die Suche auf einen bestimmten Typ.
- Verwenden Sie für die eingehende Entität ein anderes Feld, das den gewünschten Text enthält.