FAQs zum Migrationstool
Migrationstool für Regeln für die automatische Datensatzerstellung und Vereinbarungen zum Service Level (SLAs)
Wer kann auf das Migrationstool zugreifen oder es ausführen?
Administratoren und Benutzer mit CSR-Manager-Rollen können das Migrationstool ausführen.
Werden migrierte Regeln nach der Migration automatisch aktiviert?
Nein. Sie müssen die migrierten Regeln manuell aktivieren, nachdem die Migration abgeschlossen ist.
Kann ich meine Legacy-Regeln nach Ablauf der Auslauffrist noch verwenden?
Ja Ältere Legacy-Regeln werden weiterhin in vorhandenen Fällen ausgeführt, bis die Regeln deaktiviert werden. Das Bearbeitungserlebnis und die Unterstützbarkeit werden jedoch nach der Einstellung eingestellt.
Kann ich eine Regel mit einem unvollständigen Migrationsstatus aktivieren?
Nein. Eine migrierte Regel wird nur aktiviert, wenn Sie den Schalter Als abgeschlossen markieren auf Ja umstellen, nachdem Sie eine unvollständige Regel überprüft haben. Beheben Sie alle vorhandenen Probleme. Dann gilt die Regel als erfolgreich migriert.
Wird die alte Regel nach der Migration deaktiviert?
- Ja für automatische Datensatzerstellungsregeln. Wenn Sie eine migrierte automatische Datensatzerstellungs-Regel in der Einheitlichen Oberfläche aktivieren, wird die entsprechende Legacyregel deaktiviert.
- Nicht für SLAs. Wenn Sie eine migrierte SLA-Regel in der Einheitlichen Oberfläche aktivieren, bleibt die entsprechende Legacyregel aktiviert, da die beiden Regeln koexistieren können.
Was bedeutet ein unvollständiger Migrationstatus?
- Wenn er sich im Abschnitt Zusammenfassung befindet, bedeutet dies, dass der gesamte Migrationsprozess die Migration aller ausgewählten Regeln nicht erfolgreich abschließen konnte.
- Neben einer Regel: Dies bedeutet, dass entweder die Regel fehlgeschlagen ist oder nicht vollständig migriert werden konnte (d.h. ein oder mehrere Elemente oder Bedingungen konnten nicht migriert werden).
Wo finde ich eine Liste teilweise migrierter Regeln, die im Migrationstool verfolgt werden?
Regeln, die teilweise migriert sind oder als unvollständig migriert identifiziert werden, gelten nicht als vollständig migriert. Daher werden sie unter Ausstehend im Abschnitt Zusammenfassung aufgeführt. Es werden nur Regeln gezählt, die die Migration erfolgreich unter Migriert abgeschlossen haben.
Werden benutzerdefinierte Formulare oder Felder vom Migrationstool unterstützt?
- Ja für automatische Datensatzerstellungsregeln. Benutzerdefinierte Entitäten, Felder, Attribute und Konfigurationen werden vom Migrationstool unterstützt.
- Nicht für SLAs. Benutzerdefinierte Entitäten, Felder, Attribute und Konfigurationen werden nicht vom Migrationstool unterstützt. Um die Migration abzuschließen, müssen Benutzer alle vorhandenen Anpassungsabläufe, Workflows, Plugins oder anderen benutzerdefinierten Code für die benutzerdefinierten Entitäten, Felder, Attribute und Konfigurationen ändern.
Benötige ich vor dem Ausführen der Migration eine separate Lizenz für Power Automate?
Nein. Weitere Informationen zu Lizenzrichtlinien finden Sie unter Was sind Microsoft Power Apps- und Power Automate-Nutzungsrechte für Dynamics 365-Anwendungen?
Einige meiner Regeln sind unvollständig oder teilweise migriert. Was soll ich tun?
Sie können die Regel entweder im Webclient basierend auf den Problemdetails korrigieren und dann Ihre Migration erneut ausführen oder die migrierte Regel direkt in der Einheitlichen Oberfläche korrigieren.
Kann ich das Migrationstool für eine bestimmte migrierte Regel erneut ausführen?
Ja, Sie können das Migrationstool für eine bestimmte migrierte Regel basierend auf den folgenden Kriterien erneut ausführen:
- Für unvollständige oder fehlgeschlagene Migrationsregeln: Wählen Sie dieselbe Regel aus, wenn Sie das Migrationstool erneut ausführen. Das Tool ersetzt automatisch die vorhandene fehlgeschlagene oder unvollständige Regel durch die neu migrierte.
- Für erfolgreich migrierte Regeln: Löschen Sie die migrierte Regel in Einheitliche Oberfläche, bevor Sie das Migrationstool erneut ausführen.
Was passiert nach Abschluss der Migration mit vorhandenen SLA-Datensätzen, die mit älteren SLAs verknüpft sind?
- Wenn das alte SLA nach der Migration deaktiviert wird: Der Timer läuft bis zum Endstatus für solche SLA-Datensätze weiter. Allerdings wird die Funktionalität Lösen und Anhalten nicht funktionieren.
- Wenn sich das alte SLA noch im Status „Aktiv“ befindet: Vorhandene SLA-Datensätze, die mit älteren SLAs verknüpft sind, funktionieren weiterhin wie erwartet.
- Wenn Sie in den Einheitliche Oberfläche-Apps erstellte SLAs für vorhandene Datensätze verwenden möchten: Sie müssen das SLA-Feld manuell auf Einheitliche Oberfläche SLA aktualisieren oder das Plugin schreiben, um die Datensätze zu aktualisieren. Die Plugin-Logik könnte beispielsweise Modern Flow oder Workflow sein.
Informationen zu migrierten Regeln oder Abläufen in der modernen automatischen Datensatzerstellung finden Sie unter FAQ zur modernen automatischen Datensatzerstellung.
Bekannte Probleme bei der Konvertierung von Bedingungen
Dieser Abschnitt beschreibt die Schlüsselszenarien, in denen Regeln oder Elemente die Migration nicht erfolgreich abschließen.
Wenn meine Regelelemente oder Bedingungen verwandte Entitäten innerhalb einer verschachtelten Gruppenklausel (und/oder) haben, werden sie dann zur Einheitlichen Oberfläche migriert?
Nein. Derzeit unterstützen wir nur eine Ebene der zugehörigen Entitätshierarchie. Damit solche Regelelemente oder Bedingungen erfolgreich migriert werden können, müssen Sie vor der Migration alle verwandten Entitäten in der Gruppenklausel entfernen. Wenn Sie nichts unternehmen, schlägt die Regel im Schritt Untersuchung vor der Migration fehl. Wenn Sie sich dafür entscheiden, mit der Migration fortzufahren, enthält die Regel eine leere Bedingung für das zugehörige Element.
Beispiel: Verwandte Entitäten in einer verschachtelten Gruppenklausel
Vormigrationsansicht im Webclient
Legende:
a. Der Titel des Inhaltselements.
Ansicht Einheitliche Oberfläche nach der Migration
Legende:
2a. _FailedMigration wird dem Titel des migrierten Elements hinzugefügt.
2b. Der gleiche Standardplatzhalter Erstellt am entspricht 2200-01-01 wird der Bedingung hinzugefügt.
Warum schlagen meine Regelelemente oder Bedingungen mit einem DateType-Feld, das einen nicht am-Operator verwendet, während der Vormigrationsprüfung und der tatsächlichen Migration fehl?
Der Nicht auf Betreiber für den Datum Datentyp wird in Einheitliche Oberfläche nicht unterstützt. Daher wird es im Rahmen der Migration nicht unterstützt. Um dieses Problem zu beheben, können Sie die älteren Elemente oder Bedingungen von {Nicht am ausgewählten Datum} zu {Ausgewähltes Datum kleiner als und ausgewähltes Datum größer als} im Webclient ändern, bevor Sie das Migrationstool für die entsprechende Regel erneut ausführen.
Beispiel: DateType-Feld, das einen Not-On-Operator verwendet
Vormigrationsansicht im Webclient
Legende:
a. Der Titel des Inhaltselements.
Ansicht Einheitliche Oberfläche nach der Migration
Legende:
2a. _FailedMigration wird dem Titel des migrierten Elements hinzugefügt.
2b. Die Bedingung Erstellt am entspricht 2200-01-01 wird der Bedingung hinzugefügt.
Warum ändern sich die Daten in meinem DateTime-Feld während der Migration?
In Einheitliche Oberfläche ist kein separates Zeitfeld vorhanden. Deshalb änder das Feld DateTimezeit von einem Kalendersteuerelement in ein Textfeld. Die Eingabe sollte in einem bestimmten Format erfolgen, wie im folgenden Beispiel gezeigt.
Beispiel: DateTime-Feld
Vormigrationsansicht im Webclient
Legende:
a. Vormigration Feld Datum und Uhrzeit.
b. Vormigration Nur Datum-Feld.
Ansicht Einheitliche Oberfläche nach der Migration
Legende:
a. Nach der Migration Datum und Uhrzeit Feld.
b. Nach der Migration Nur Datum-Feld.
Warum sind einige meiner Operatorfelder in der Einheitlichen Oberfläche nach der Migration leer?
Für Suchdatentypen werden nur die gleich, nicht gleich, null und nicht null-Operatoren in der Einheitlichen Oberfläche und im Migrationstool unterstützt. Unter und nicht unter-Operatoren werden in der Einheitlichen Oberfläche nicht unterstützt und daher auch im Migrationstool nicht unterstützt. Alle Bedingungen, die unter oder nicht-unter Operatoren haben, werden als nach der Migration als bezogene Entitäten übersetzt. Sie werden in Einheitliche Oberfläche als leer angezeigt und können nicht bearbeitet werden.
Beispiel: Unter- und Nicht-unter-Operatorfelder
Vormigrationsansicht im Webclient
Legende:
a.Unter Operatoren.
Ansicht Einheitliche Oberfläche nach der Migration
Legende:
b. Leeres Operatorfeld.
Anmerkung
Die folgenden Einschränkungen gelten beim Definieren einer Bedingung im Kundenservice Hub:
- Das Steuerelement „Datums- und Uhrzeitauswahl“ ist in den Bedingungen nicht mehr verfügbar. Sie können Datum und Uhrzeit jedoch weiterhin im Textfeld bearbeiten.
- Derzeit unterstützen wir nur eine Ebene der zugehörigen Entitätshierarchie. Sie können jedoch verschachtelte, verwandte Entitäten in der Anwendung auswählen.
- Die verwandte Entität in einer Gruppe der und/oder-Klausel wird nicht unterstützt.
- Der Operator Nicht am für den Datentyp Datum wird nicht unterstützt.
- Für den Suchdatentyp Suche werden nur die Operatoren gleich, ungleich, null und ungleich null unterstützt. Unter und Nicht unter-Operatoren werden nicht unterstützt.
Kann ich eine Regel nach ihrer Aktivierung erneut migrieren?
- Ja für automatische Datensatzerstellungsregeln. Sie können eine aktivierte Regel erneut migrieren, müssen sie jedoch zuerst deaktivieren und aus der Einheitlichen Oberfläche löschen, bevor Sie sie erneut migrieren können.
- Nicht für SLAs. Nachdem eine migrierte SLA-Regel aktiviert wurde, wird sie mit einer anderen Entität verknüpft (z. B. einem Fall) oder ist in Verwendung. Standardmäßig wurde eine aktivierte Regel erfolgreich migriert. Bevor Sie eine aktive Regel wieder migrieren können, müssen Sie sie zuerst deaktivieren. Es gibt jedoch eine Einschränkung für die SLA-Regeln Einheitliche Oberfläche. Nachdem eine Regel einem Fall oder einer Entität zugeordnet wurde (d. h. nachdem sie einmal aktiviert wurde), können Sie sie nicht löschen, auch wenn sie deaktiviert ist. Daher kann die Regel nicht erneut migriert werden, wenn sie zuvor aktiviert oder angewendet wurde.
Kann ich veraltete Standard-SLA-Regeln migrieren?
Nein. Das Migrationstool unterstützt nur erweiterte SLA-Regeln. Standard-SLA-Regeln sind veraltet. Sie werden in der Einheitlichen Oberfläche nicht mehr unterstützt und daher auch im Migrationstool nicht unterstützt. Weitere Informationen finden Sie unter Standard-SLAs in Dynamics 365 Customer Service sind veraltet.
Bekannte Probleme
Außer Betrieb genommene Kanaleigenschaft
Wenn Sie bei der Anpassung älterer Regeln Kanaleigenschaften verwendet haben, werden diese Regeln vom Migrationstool nicht erfolgreich migriert. Es gibt keine allgemeine Problemumgehung, mit der diese Lücke für alle Benutzer behoben werden kann. Die Problemumgehung hängt stark davon ab, wie Sie die Kanaleigenschaften in den alten Regeln verwenden.
Verhaltensunterschiede, wenn Sie die Option Erstellen von Anfragen für die einer abgeschlossene Anfrage zugeordneten Aktivitäten aktivieren wählen.
- Legacy-Verhalten: Wenn die E-Mail einen zugehörigen Fall enthält, der seit dem angegebenen Zeitpunkt gelöst wurde, wird der gelöste Fall standardmäßig reaktiviert. Keine Anpassung erforderlich.
- Neues Verhalten: Wenn die E-Mail einen zugehörigen Fall enthält, der seit dem angegebenen Zeitpunkt gelöst wurde, wird standardmäßig ein neuer Fall erstellt. Eine Anpassung ist erforderlich, um einen vorhandenen Fall zu reaktivieren, anstatt einen neuen Fall zu erstellen.
Verhaltensunterschied, wenn die Option Fall erstellen, wenn für den Kunden eine gültige Berechtigung besteht ausgewählt ist
- Legacy-Verhalten: Wenn der E-Mail-Absender keine gültige Berechtigung hat und die E-Mail einen zugehörigen Fall enthält, wird der vorhandene zugehörige Fall aktualisiert.
- Neues Verhalten: Wenn der E-Mail-Absender keine gültige Berechtigung hat, wird kein Flow aufgerufen.
Paritätslücken zwischen Arbeitsabläufen und Power Automate Abläufen (gilt nur für die Anpassung von Regelelementaktionen)
- „First not null“-Ausdrücke können nicht automatisch migriert werden. Für die Migration können jedoch Anpassungen manuell auf den Ablauf angewendet werden.
- Die Zuordnung des Anzeigename eines Nachschlagedatensatzes zu einem Zeichenfolgenfeld kann nicht automatisch migriert werden. Für die Migration können jedoch Anpassungen manuell auf den Ablauf angewendet werden.
- Felder der Aktivitätspartei, die als Quellfelder verwendet werden, werden im Flow nicht unterstützt.
Bekannte Flowprobleme
Migrierte Regeln haben ein zusätzliches @-Zeichen für Felder mit dem @-Zeichenfolgentyp
Wenn der alte Workflow für automatische Datensatzerstellungsregeln angepasst ist und in einem Zeichenfolgenfeld ein Nur-Text-@-Zeichen enthält, werden bei der Migration zwei @-Zeichen anstelle von einem angezeigt. Wenn Sie beispielsweise im Feld „Anfragebeschreibung“ eine E-Mail-Adresse im Klartext hinzufügen, wird das @-Zeichen als Sonderzeichen behandelt und als @@ migriert.
Dies liegt daran, dass @ als Sonderzeichen für jeden dynamischen Ausdruck identifiziert wird, z. B. @triggerOutputs()?[body/_emailsender_value] im Migrationsflow.
Die Problemumgehung besteht darin, das zusätzliche @ im migrierten Flow manuell zu entfernen.
Die Migration unterstützt nicht mehrere Elemente oder Bedingungen mit demselben „gilt bei“ innerhalb derselben SLA
Im Webclient können mehrere Elemente mit derselben Bedingung „anwendbar, wenn“ und unterschiedlichen Erfolgskriterien für eine SLA definiert werden. Dieselbe Funktion wird jedoch in der einheitlichen Oberfläche nicht unterstützt. Daher wird während der Migration kein zweites oder nachfolgendes solches SLA-Element mit derselben Bedingung anwendbar, wenn erstellt.
Die folgenden Screenshots zeigen das Szenario, das in der Einheitlichen Oberfläche nicht unterstützt wird. Die zwei Bedingungen anwendbar, wenn, die mit unterschiedlichen Erfolgskriterien angezeigt werden.
Probleme mit Attributen des Aktivitätsparteityps während der Konvertierung von Workflow in Flow
Ein Attribut vom Aktivitätsparteityp, das einem anderen Feld vom Aktivitätsparteityp zugewiesen ist, wird während der Konvertierung von Workflow zu Flow nicht migriert, da Power Automate dieses Szenario derzeit nicht unterstützt. (Die am häufigsten betroffenen Felder sind An, Von, CC und BCC Felder in E-Mails.). Obwohl die Migration der Regel nicht fehlschlägt, ist der Datenwert für solche Felder vom Typ Aktivitätspartei, die sich auf ein anderes Attribut vom Typ Aktivität beziehen nach nach der Migration leer.
Beispiel: Attribute des Aktivitätsparteityps
Vormigrationsansicht im Webclient
Legende:
a. Das Von Feld, bei dem es sich um ein Feld für einen Aktivitätspartnertyp handelt, dem ein anderes Attribut für einen Aktivitätspartnertyp {Bcc(E-Mail)} zugewiesen ist. Nach der Migration ist es leer.
b. Das An Feld wird migriert.
Ansicht Einheitliche Oberfläche nach der Migration
Legende:
b.An Feld.
Erste-nicht-NULL-Prüfungen von Ausdrücken im Legacy-Workflow werden während der Konvertierung von Workflow-to-Flow-Konvertierung nicht unterstützt.
In älteren Workflows kann ein Suchfeld mehreren Ausdrücken zugeordnet werden, wobei Sie den Erster nicht NULL-Ausdruck prüfen und zuweisen, wie im nachfolgenden Webclientbeispiel gezeigt. Aufgrund von bekannten Einschränkungen im Legacy-Workflow-Designer wird dieser Ansatz im Rahmen der Konvertierung von Workflow-zu-Flow nicht unterstützt. Daher weist der Workflow-Konverter den ersten Ausdruck zu, ohne die Nullprüfung durchzuführen. Anschließend werden alle verbleibenden Ausdrücke entfernt, unabhängig davon, ob sie Werte ungleich Null haben. Im folgenden Beispiel hat der Flow innerhalt dieses Schrittes nur In Bezug auf (E-Mail) im Feld Kunde.
Beispiel: Erste Nicht-Nullull-Ausdrücke
Ansicht vor der Migration:
Legende:
a.Ansicht Webclient: Im Workflow enthält das Feld Kunde: {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.
In Einheitliche Oberfläche hat das Feld Kunde nur Regarding(Email), unabhängig davon, ob es Null ist.
Wichtig
Wenn weiterhin Probleme mit dem Migrationstool auftreten, wenden Sie sich an Ihren Administrator oder den Microsoft-Support.
Siehe auch
FAQ zu moderner automatischer Datensatzerstellung
Regeln für automatische Datensatzerstellung und SLAs migrieren