Risolvere i problemi di configurazione comuni relativi alle regole di creazione e aggiornamento automatici dei record
Questo articolo fornisce soluzioni per scenari di errore di configurazione comuni con regole di aggiornamento e creazione automatica di record, a causa delle quali la creazione di record potrebbe non riuscire o essere ignorata.
Scenario 1
Esempio: Configurazione nella regola di creazione e aggiornamento automatica dei record
- L'opzione Crea contatto per il mittente sconosciuto deve essere selezionata.
- Impostare i criteri di condizione su Qualsiasi messaggio di posta elettronica in arrivo.
- Aggiungere un'azione per creare un caso, selezionare Visualizza proprietà e impostare i campi case per caso d'uso aziendale.
Errore 1 : "Il caso manca al cliente"
Nel campo Customer (Cliente) della sezione CASE DETAILS (DETTAGLI CASE) il valore di Senders Account (Email) viene impostato come illustrato di seguito.
Questa impostazione genera l'errore seguente nei processi di sistema:
Il caso è un cliente mancante.
Risoluzione dell'errore 1
Per risolvere il problema, mantenere vuoto il campo Cliente o impostarlo su {Sender(Email)}. In questo modo il sistema può creare automaticamente un contatto per il mittente sconosciuto e collegarlo al caso.
Errore 2 - "Si è verificato un errore"
Il campo Cliente è impostato su {Account mittenti(Email)}, mentre il campo Contatto è impostato su {Sender(Email)}.
Questa impostazione genera l'errore seguente nei processi di sistema:
Si è verificato un errore. Provare di nuovo questa azione. Se il problema persiste, controllare la Dynamics 365 Community Microsoft per individuare soluzioni o contattare l'amministratore microsoft Dynamics 365 dell'organizzazione. Infine, è possibile contattare supporto tecnico Microsoft.
Risoluzione dell'errore 2
Per risolvere il problema, mantenere vuoto il campo Cliente o impostarlo su {Sender(Email)}. In questo modo il sistema può creare automaticamente un contatto per il mittente sconosciuto e collegarlo al caso.
Errore 3: "Il contatto specificato non appartiene al contatto specificato nel campo del cliente".
I campi Cliente e Contatto sono impostati su {Sender(Email)}.
Questa impostazione genera l'errore seguente nei processi di sistema:
Il contatto specificato non appartiene al contatto specificato nel campo del cliente. Rimuovere il valore dal campo contatto oppure selezionare un contatto associato al cliente selezionato e quindi riprovare.
Risoluzione dell'errore 3
Per risolvere il problema, lasciare vuoto il campo Contatto e impostare il campo Cliente su vuoto o su {Sender(Email)}.
Passaggi di convalida
È necessario convalidare i passaggi di configurazione e convalida forniti nella tabella seguente per comprendere la causa principale del problema e risolverlo.
| Opzione in Creazione automatica record e regola di aggiornamento nella gestione dei servizi | Se selezionata come | Passaggi di convalida | Risultato |
|---|---|---|---|
| Creare un caso se esiste un diritto valido per il cliente | Sì | Verificare che esista un diritto attivo per il cliente. Il diritto attivo valido viene valutato come segue: - Se il mittente dell'e-mail è un contatto con un account padre, Dynamics 365 servizio clienti crea un caso se l'account padre del contatto ha un diritto valido e il contatto è elencato nella sezione Contatti del diritto Oppure, - Se la sezione Contatti è vuota (il che significa che il diritto è applicabile a tutti i contatti per il cliente) |
Viene creato un case. |
| Creare un caso da un messaggio di posta elettronica inviato da mittenti sconosciuti | Sì | Per qualsiasi messaggio di posta elettronica in arrivo da un mittente sconosciuto | - Viene creato un case.
- Viene creato anche un contatto per il mittente sconosciuto. |
| Sì | Per un messaggio di posta elettronica in arrivo con indirizzo di posta elettronica di un account o di un contatto inattivo | - Viene creato un case.
- Viene attivato un account o un contatto inattivo. |
|
| No | Per un messaggio di posta elettronica in arrivo con indirizzo di posta elettronica dell'account o del contatto attivo | Viene creato un case. | |
| No | Per un messaggio di posta elettronica in arrivo inviato da un tipo di record diverso dall'account o dal contatto | Non viene creato alcun caso. | |
| No | Per un messaggio di posta elettronica in arrivo con indirizzo di posta elettronica di un account o di un contatto inattivo | Non viene creato alcun caso. | |
| Creare un caso per le attività associate a un caso risolto | Sì | Per un messaggio di posta elettronica in ingresso correlato a un caso risolto | Viene creato un case. |
| Sì | Per un messaggio di posta elettronica in ingresso correlato a un caso attivo | Non viene creato alcun caso. |
Scenario 2: l'uso di {Regarding(Email)} nell'esperienza legacy non fornisce i dati corretti nel flusso
Negli elementi legacy "automatic record creation and update rules" in Customer Service, per cercare l'entità (un contatto o un account) che invia un messaggio di posta elettronica, è possibile usare la ricerca polimorfica Sender (Email), che recupera automaticamente l'entità appropriata e visualizza il nome dell'entità. Le ricerche polimorfiche sono ricerche in cui la destinazione della ricerca è più di un tipo di entità. Ad esempio, può puntare a un contatto o a un account. Tuttavia, nelle moderne "regole di creazione e aggiornamento automatico dei record", questa visualizzazione automatica non è supportata, quindi è necessario specificare il tipo di entità che si vuole recuperare insieme ai campi da visualizzare da tale entità.
Causa
Un flusso non usa il valore {Regarding(Email)} come un flusso di lavoro legacy perché le espressioni di flusso fanno riferimento a un valore di dati da uno dei payload del passaggio del flusso precedente. Ad esempio, se il valore {Regarding(Email)} è vuoto all'inizio del flusso, il valore nel payload del passaggio del trigger per {Regarding(Email)} rimarrà vuoto. Anche se il valore {Regarding(Email)} viene aggiornato dopo la creazione di un case, i dati del record di posta elettronica vengono aggiornati, ma il payload nel flusso non lo fa. Pertanto, quando viene fatto riferimento al valore del payload nei passaggi successivi del flusso, rimane vuoto.
Risoluzione
Se il valore {Regarding(Email)} viene usato negli elementi delle regole legacy, è necessario aggiornare manualmente il flusso migrato per usare "ID evento imprevisto" o "ID OData". Usare l'"ID OData" per i campi che richiedono riferimenti o ricerche di entità. Usare l'identificatore univoco del caso per i campi che richiedono GUID.
Scenario 3 - Problemi con il rendering di ricerche polimorfiche nei campi non di ricerca durante la migrazione da legacy a moderne "regole di creazione e aggiornamento automatica dei record"
Un elemento legacy "automatic record creation and update rules" usando ricerche polimorfiche, ad esempio Sender, genera una ricerca non valida quando viene assegnato a un campo di testo.
Negli elementi legacy relativi alla creazione automatica dei record e alle regole di aggiornamento nel servizio clienti, per cercare l'entità (un contatto o un account) che ha inviato un messaggio di posta elettronica, è possibile usare la ricerca polimorfica Mittente (Email), che recupera automaticamente l'entità appropriata e visualizza il nome dell'entità. Le ricerche polimorfiche sono ricerche in cui la destinazione della ricerca è più di un tipo di entità. Ad esempio, può puntare a un contatto o a un account. Tuttavia, nelle moderne "regole di creazione e aggiornamento automatica dei record", questa visualizzazione automatica non è supportata. È quindi necessario specificare il tipo di entità da recuperare insieme ai campi da visualizzare da tale entità.
Causa
Il comportamento del flusso di lavoro classico usato dalle "regole di creazione e aggiornamento automatica dei record" legacy presenta molti comportamenti nascosti. Ad esempio, determinare automaticamente il tipo di entità e recuperare un campo come nome visualizzato se il parametro viene usato in una stringa, ma restituendo l'ID se assegnato a un campo di ricerca. Il codice di migrazione della piattaforma usato dalle "regole di creazione e aggiornamento automatici dei record" durante la conversione da flussi di lavoro legacy a flussi di lavoro moderni non aggiunge i passaggi e i campi necessari.
Risoluzione
Per risolvere questo problema,
- Aggiornare la ricerca a un tipo specifico.
- Usare un campo diverso nell'entità in ingresso che contiene il testo desiderato.