Freigeben über


Behandeln allgemeiner Konfigurationsprobleme bei automatischen Datensatzerstellungs- und Aktualisierungsregeln

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 automatische Datensatzerstellung und -aktualisierungsregel

  • Die Option Kontakt für unbekannten Absender erstellen sollte ausgewählt sein.
  • Legen Sie 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 der Kunde"

Im Feld Kunde des Abschnitts CASE DETAILS wird der Wert des Absenderkontos (Email) wie unten dargestellt festgelegt.

Screenshot, der zeigt, wie der Wert des Absenderkontos (Email) im Feld

Diese Einstellung führt in Systemaufträgen zu folgendem Fehler:

Der Fall fehlt der Kunde.

Screenshot, der die Details des Fehlers zeigt, der angibt, dass der Fall den Kunden fehlt.

Lösung für Fehler 1

Um dieses Problem zu beheben, lassen Sie das Feld Kunde leer, oder legen Sie es auf {Sender(Email)} fest. Dadurch 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 ist auf {Senders Account(Email)} festgelegt, und das Feld Kontakt ist auf {Sender(Email)} festgelegt.

Screenshot: Festgelegte Werte für die Felder

Diese Einstellung führt in Systemaufträgen zu folgendem Fehler:

Es ist ein Fehler aufgetreten. Versuchen Sie diese Aktion 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 Ihres organization. Schließlich können Sie sich an Microsoft-Support wenden.

Screenshot: Details des Fehlers, der aufgrund des für das Feld

Lösung für Fehler 2

Um dieses Problem zu beheben, lassen Sie das Feld Kunde leer, oder legen Sie es auf {Sender(Email)} fest. Dadurch 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 zu dem Kontakt, der im Kundenfeld angegeben wurde."

Die Felder Kunde und Kontakt sind auf {Sender(Email)} festgelegt.

Screenshot: Festgelegter Wert für die Felder

Diese Einstellung führt in Systemaufträgen zu folgendem Fehler:

Der angegebene Kontakt gehört nicht zu dem 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.

Screenshot: Details des Fehlers, der angibt, dass der angegebene Kontakt nicht zu dem Kontakt gehört, der im Feld

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 {Absender(Email)} fest.

Validierungsschritte

Sie müssen die in der folgenden Tabelle aufgeführten Konfigurations- und Validierungsschritte überprüfen, um die Standard Ursache des Problems zu verstehen und es zu beheben.

Option in der Regel für automatische Datensatzerstellung und -aktualisierung in der Dienstverwaltung Wenn ausgewählt als Validierungsschritte Ergebnis
Erstellen eines Falls, wenn eine gültige Berechtigung für den Kunden vorhanden ist Ja Überprüfen Sie, ob eine aktive Berechtigung für den Kunden vorhanden ist. Die gültige aktive Berechtigung wird wie folgt ausgewertet:
- Wenn der Absender der E-Mail ein Kontakt mit einem übergeordneten Konto ist, erstellt 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
oder, - Wenn der Abschnitt Kontakte leer ist (d. h.,
die Berechtigung gilt für alle Kontakte für den Kunden)
Ein Fall wird erstellt.
Erstellen eines Falls aus einer E-Mail, die von unbekannten Absendern gesendet wurde Ja Für alle eingehenden E-Mails von einem unbekannten Absender – Ein Fall wird erstellt.
– Ein Kontakt wird auch für den unbekannten Absender erstellt.
Ja Für eine eingehende E-Mail mit der E-Mail-Adresse des inaktiven Kontos oder Kontakts – Ein Fall wird erstellt.
– Ein inaktives Konto oder Kontakt wird aktiviert.
Nein Für eine eingehende E-Mail mit der E-Mail-Adresse des aktiven Kontos oder Kontakts Ein Fall wird erstellt.
Nein Für eine eingehende E-Mail, die von einem anderen Datensatztyp als Konto oder Kontakt gesendet wird Es wird kein Fall erstellt.
Nein Für eine eingehende E-Mail mit der E-Mail-Adresse des inaktiven Kontos oder Kontakts Es wird kein Fall erstellt.
Erstellen eines Falls für Aktivitäten, die einem gelösten Fall zugeordnet sind Ja Für eine eingehende E-Mail im Zusammenhang mit einem gelösten Fall Ein Fall wird erstellt.
Ja Für eine eingehende E-Mail im Zusammenhang mit einem aktiven Fall Es wird kein Fall erstellt.

Szenario 2: Die Verwendung von {Regarding(Email)} in der Legacyumgebung gibt nicht die richtigen Daten im Fluss.

In älteren Elementen für die automatische Datensatzerstellung und -aktualisierung im Kundendienst können Sie zum Suchen der Entität (entweder ein Kontakt oder ein Konto), die eine E-Mail sendet, die polymorphe Absendersuche (Email) verwenden, die automatisch die entsprechende Entität abruft und den Namen der Entität anzeigt. Polymorphe Lookups sind Lookups, bei denen das Ziel der Suche mehr als eine Entitätsart ist. Sie kann z. B. 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 abrufen möchten, sowie die Felder, die von dieser Entität angezeigt werden sollen.

Ursache

Ein Flow verwendet den {Regarding(Email)}-Wert nicht wie ein Legacyworkflow, da Flussausdrücke auf einen Datenwert aus einer der Nutzlasten des vorherigen Flowschritts verweisen. Wenn beispielsweise der {Regarding(Email)}-Wert leer ist, wenn der Flow beginnt, bleibt der Wert in der Nutzlast des Triggerschritts für {Regarding(Email)} leer. Auch wenn der {Regarding(Email)}-Wert aktualisiert wird, nachdem ein Fall erstellt wurde, werden die E-Mail-Datensatzdaten aktualisiert, die Nutzlast im Fluss jedoch nicht. Wenn also in den nachfolgenden Flowschritten auf den Wert aus der Nutzlast verwiesen wird, bleibt er leer.

Lösung

Wenn der {Regarding(Email)}-Wert in Legacyregelelementen verwendet wird, müssen Sie den migrierten Flow manuell aktualisieren, um die "Incident-ID" oder "OData-ID" zu verwenden. Verwenden Sie die "OData-ID" für Felder, die Einen Entitätsverweis oder Nachschlagevorgänge erfordern. Verwenden Sie den eindeutigen Bezeichner für Felder, die eine GUID erfordern.

Szenario 3: Probleme beim Rendern polymorpher Suchvorgänge für Nicht-Nachschlagefelder während der Migration von legacy zu modernen Regeln für die automatische Datensatzerstellung und -aktualisierung

Ein älteres Element "Regeln für die automatische Datensatzerstellung und -aktualisierung" mit polymorphen Nachschlagevorgängen, z. B . Absender, führt zu einer ungültigen Suche, wenn es einem Textfeld zugewiesen wird.

In älteren Elementen für die automatische Datensatzerstellung und -aktualisierung im Kundendienst können Sie die entität (entweder ein Kontakt oder ein Konto), die eine E-Mail gesendet hat, mithilfe des polymorphen Absenders (Email) nachschlagen, der automatisch die entsprechende Entität abruft und den Namen der Entität anzeigt. Polymorphe Lookups sind Lookups, bei denen das Ziel der Suche mehr als eine Entitätsart ist. Sie kann z. B. 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 abrufen möchten, zusammen mit den Feldern, die von dieser Entität angezeigt werden sollen.

Ursache

Das klassische Workflowverhalten, das von älteren "Regeln zur automatischen Datensatzerstellung und -aktualisierung" verwendet wird, weist viele ausgeblendete Verhaltensweisen auf. Beispielsweise wird automatisch der Entitätstyp bestimmt und ein Feld als Anzeigename abgerufen, wenn der Parameter in einer Zeichenfolge verwendet wird, aber die ID zurückgibt, wenn er einem Nachschlagefeld zugewiesen ist. Der Plattformmigrationscode, der "Regeln für die automatische Datensatzerstellung und -aktualisierung" bei der Konvertierung von Legacy- in moderne Workflows verwendet, fügt nicht die erforderlichen Schritte und Felder hinzu.

Lösung

Um dieses Problem zu beheben,

  • Aktualisieren Sie die Suche auf einen bestimmten Typ.
  • Verwenden Sie ein anderes Feld für die eingehende Entität, die den gewünschten Text enthält.