Rozwiązywanie typowych problemów z konfiguracją przy użyciu automatycznych reguł tworzenia i aktualizowania rekordów
Ten artykuł zawiera rozwiązania typowych scenariuszy błędów konfiguracji z automatycznymi regułami tworzenia rekordów i aktualizacji, z powodu których tworzenie rekordu może zakończyć się niepowodzeniem lub pominięciem.
Scenariusz 1
Przykład: konfiguracja automatycznego tworzenia rekordów i reguły aktualizacji
- Należy wybrać opcję Utwórz kontakt dla nieznanego nadawcy.
- Określ kryteria warunku na Wszystkie przychodzące wiadomości e-mail.
- Dodaj akcję, aby utworzyć przypadek, wybierz pozycję Wyświetl właściwości i ustaw pola przypadku dla każdego przypadku użycia biznesowego.
Błąd 1 — "Brak klienta w przypadku"
W polu Klient w sekcji SZCZEGÓŁY PRZYPADKU wartość konta nadawców (e-mail) jest ustawiona, jak pokazano poniżej.
To ustawienie powoduje następujący błąd w zadaniach systemowych:
W przypadku brakuje klienta.
Rozwiązanie błędu 1
Aby rozwiązać ten problem, pozostaw pole Klient puste lub ustaw je na {Sender(Email)}. Dzięki temu system może automatycznie utworzyć kontakt dla nieznanego nadawcy i połączyć go ze sprawą.
Błąd 2 — "Wystąpił błąd"
Pole Customer (Klient ) jest ustawione jako {Senders Account(Email)}, a pole Kontakt jest ustawione na {Sender(Email)}.
To ustawienie powoduje następujący błąd w zadaniach systemowych:
Wystąpił błąd. Spróbuj ponownie wykonać tę akcję. Jeśli problem będzie nadal występować, sprawdź Społeczność użytkowników usługi Dynamics 365 firmy Microsoft pod kątem rozwiązań lub skontaktuj się z administratorem usługi Microsoft Dynamics 365 w organizacji. Na koniec możesz skontaktować się z pomoc techniczna firmy Microsoft.
Rozwiązanie błędu 2
Aby rozwiązać ten problem, pozostaw pole Klient puste lub ustaw je na {Sender(Email)}. Dzięki temu system może automatycznie utworzyć kontakt dla nieznanego nadawcy i połączyć go ze sprawą.
Błąd 3 — "Określony kontakt nie należy do kontaktu określonego w polu klienta".
Pola Klient i Kontakt są ustawiane jako {Sender(Email)}.
To ustawienie powoduje następujący błąd w zadaniach systemowych:
Określony kontakt nie należy do kontaktu określonego w polu klienta. Usuń wartość z pola kontakt lub wybierz kontakt skojarzony z wybranym klientem, a następnie spróbuj ponownie.
Rozwiązanie błędu 3
Aby rozwiązać ten problem, pozostaw puste pole Kontakt i ustaw pole Klient na puste lub {Sender(Email)}.
Kroki sprawdzania poprawności
Należy zweryfikować kroki konfiguracji i weryfikacji podane w poniższej tabeli, aby zrozumieć główną przyczynę problemu i rozwiązać go.
Opcja w Automatyczne tworzenie rekordu i reguła aktualizacji w Zarządzanie usługami | Jeśli wybrano jako | Kroki sprawdzania poprawności | Wynik |
---|---|---|---|
Utwórz sprawę, jeśli istnieje prawidłowe uprawnienie dla klienta | Tak | Potwierdź, że istnieje prawidłowe uprawnienie dla klienta. Prawidłowe aktywne uprawnienie jest oceniane jak poniżej: — jeśli nadawca wiadomości e-mail jest kontaktem z kontem nadrzędnym, usługa Dynamics 365 Customer Service tworzy przypadek, jeśli konto nadrzędne kontaktu ma prawidłowe uprawnienie, a kontakt jest wymieniony w sekcji Kontakty uprawnienia Lub — jeśli sekcja Kontakty jest pusta (co oznacza, że uprawnienie ma zastosowanie do wszystkich kontaktów dla klienta) |
Zostanie utworzony przypadek. |
Utwórz sprawę z wiadomości e-mail od nieznanych nadawców | Tak | Dla dowolnej wiadomość e-mail od nieznanego nadawcy | — Jest tworzony przypadek. — Dla nieznanego nadawcy jest również tworzony kontakt. |
Tak | Dla przychodzącej wiadomości e-mail, z adresem e-mail nieaktywnego konta lub kontaktu | — Jest tworzony przypadek. — Aktywowano nieaktywne konto lub kontakt. |
|
Nie. | Dla przychodzącej wiadomości e-mail, z adresem e-mail aktywnego konta lub kontaktu | Zostanie utworzony przypadek. | |
Nie. | Dla przychodzącej wiadomości e-mail wysłanej przez typu rekordu inny niż konto lub kontakt | Nie utworzono wielkości liter. | |
Nie. | Dla przychodzącej wiadomości e-mail, z adresem e-mail nieaktywnego konta lub kontaktu | Nie utworzono wielkości liter. | |
Utwórz sprawę dla działań skojarzonych z rozwiązaną sprawą | Tak | Dla przychodzącej wiadomości e-mail dotyczącej rozwiązanej sprawy | Zostanie utworzony przypadek. |
Tak | Dla przychodzącej wiadomości e-mail dotyczącej aktywnej sprawy | Nie utworzono wielkości liter. |
Scenariusz 2 — użycie elementu {Regarding(Email)} w starszym środowisku nie daje prawidłowych danych w przepływie
W starszych elementach "automatyczne tworzenie rekordów i aktualizowanie reguł" w usłudze klienta, aby wyszukać jednostkę (kontakt lub konto), która wysyła wiadomość e-mail, możesz użyć wielomorficznego wyszukiwania nadawcy (e-mail ), który automatycznie pobiera odpowiednią jednostkę i wyświetla nazwę jednostki. Polimorficzne lookiwyszkiwania to takie, w których celem jest więcej niż jeden rodzaj encji. Na przykład może wskazywać na kontakt albo na konto. Jednak w nowoczesnych "automatycznych regułach tworzenia i aktualizowania rekordów" ten automatyczny ekran nie jest obsługiwany, dlatego należy określić typ jednostki, którą chcesz pobrać wraz z polami do wyświetlenia z tej jednostki.
Przyczyna
Przepływ nie używa wartości {Regarding(Email)} , takiej jak starszy przepływ pracy, ponieważ wyrażenia przepływu odwołują się do wartości danych z jednego z ładunków poprzedniego kroku przepływu. Na przykład, jeśli wartość {Regarding(Email)} jest pusta, gdy rozpoczyna się przepływ, wartość w ładunku użytecznym kroku wyzwalającego dla {Regarding(Email)} pozostanie pusta. Nawet jeśli wartość {Regarding(Email)} zostanie zaktualizowana po utworzeniu przypadku, dane rekordu poczty e-mail zostaną zaktualizowane, ale ładunek w przepływie nie zostanie zaktualizowany. Tak więc, gdy wartość z ładunku jest przywoływana w kolejnych krokach przepływu, pozostaje pusta.
Rozwiązanie
Jeśli wartość {Regarding(Email)} jest używana w starszych elementach reguły, musisz ręcznie zaktualizować zmigrowany przepływ, aby użyć identyfikatora zdarzenia lub identyfikatora OData. Użyj pola "OData Id", które wymagają odwołania do jednostki lub odnośników. Użyj unikatowego identyfikatora wielkości liter dla pól, które wymagają identyfikatora GUID.
Scenariusz 3 — problemy z renderowaniem wielomorficznych odnośników w polach nienależących do wyszukiwania podczas migracji ze starszej wersji do nowoczesnego "automatycznego tworzenia rekordów i reguł aktualizacji"
Starszy element "automatyczne tworzenie rekordów i aktualizowanie reguł" przy użyciu wielomorficznych odnośników, takich jak Sender, powoduje nieprawidłowe wyszukiwanie po przypisaniu do pola tekstowego.
W starszych elementach "automatycznego tworzenia rekordu i aktualizowania reguł" w usłudze klienta, aby wyszukać jednostkę (kontakt lub konto), które wysłały wiadomość e-mail, możesz użyć wielomorficznego wyszukiwania nadawcy (e-mail ), który automatycznie pobiera odpowiednią jednostkę i wyświetla nazwę jednostki. Polimorficzne lookiwyszkiwania to takie, w których celem jest więcej niż jeden rodzaj encji. Na przykład może wskazywać na kontakt albo na konto. Jednak w nowoczesnych "automatycznych regułach tworzenia i aktualizowania rekordów" ten automatyczny ekran nie jest obsługiwany. Dlatego należy określić typ jednostki, którą chcesz pobrać wraz z polami do wyświetlenia z tej jednostki.
Przyczyna
Klasyczne zachowanie przepływu pracy używane przez starsze "automatyczne tworzenie rekordów i reguły aktualizacji" ma wiele ukrytych zachowań. Na przykład automatyczne określanie typu jednostki i pobieranie pola jako nazwy wyświetlanej, jeśli parametr jest używany w ciągu, ale zwraca identyfikator, jeśli został przypisany do pola odnośnika. Kod migracji platformy używany przez "automatyczne tworzenie rekordów i reguły aktualizacji" podczas konwertowania ze starszej wersji na nowoczesne przepływy pracy nie dodaje wymaganych kroków i pól.
Rozwiązanie
Aby rozwiązać ten problem,
- Zaktualizuj wyszukiwanie do określonego typu.
- Użyj innego pola na przychodzącej encji, który zawiera pożądany tekst.