Condividi tramite


Domande frequenti sullo strumento di migrazione

Strumento di migrazione per regole di creazione automatica di record e contratti di servizio

Chi può accedere allo strumento di migrazione o eseguirlo?

Gli amministratori e gli utenti con ruoli di responsabile CSR possono eseguire lo strumento di migrazione.

Le regole migrate vengono attivate automaticamente dopo la migrazione?

Nr. Devi attivare manualmente le regole migrate al termine della migrazione.

Posso ancora utilizzare le mie regole precedenti dopo la scadenza del ritiro?

Sì. Le regole legacy attive continuano a essere eseguite dopo la scadenza della deprecazione, finché non vengono disattivate. Tuttavia, l'esperienza di modifica e la supportabilità vengono interrotte dopo la deprecazione.

Posso attivare una regola il cui stato di migrazione è "Incompleta"?

Nr. Una regola migrata viene attivata solo quando imposti l'interruttore Contrassegna come completata su dopo aver esaminato una regola incompleta e risolto eventuali problemi presenti. Questo è il momento in cui la migrazione della regola viene considerata riuscita.

La regola legacy viene disattivata dopo la migrazione?

  • Per la creazione automatica di record, sì. Quando attivi una regola di creazione automatica di record migrata in Unified Interface, la regola legacy corrispondente viene disattivata.
  • Per i contratti di servizio, no. Quando attivi una regola di contratto di servizio migrata in Unified Interface, la regola legacy corrispondente rimane attiva perché le due regole possono coesistere.

Cosa significa lo stato "Incompleta" di una migrazione?

  • Nella sezione Riepilogo: il processo di migrazione globale non è riuscito a completare correttamente la migrazione di tutte le regole selezionate.
  • Accanto a una regola: la regola non è riuscita oppure non è stato possibile migrarla completamente (ovvero uno o più elementi o condizioni non sono stati migrati).

Dove posso trovare un elenco di regole parzialmente migrate registrate nello strumento di migrazione?

Le regole di cui è stata eseguita la migrazione parziale o identificate come migrate in modo incompleto non sono considerate completamente migrate. Pertanto, vengono elencate in In attesa nella sezione Riepilogo. Solo le regole la cui migrazione è stata completata correttamente vengono elencate in Migrate.

Lo strumento di migrazione supporta moduli o campi personalizzati?

  • Per la creazione automatica di record, sì. Lo strumento di migrazione supporta entità, campi, attributi e configurazioni personalizzati.
  • Per i contratti di servizio, no. Lo strumento di migrazione non supporta integralmente entità, campi, attributi e configurazioni personalizzati. Per completare la migrazione, gli utenti devono modificare eventuali flussi di personalizzazione, flussi di lavoro, plug-in o altro codice personalizzato in entità, campi, attributi e configurazioni personalizzati.

Ho bisogno di una licenza separata per Power Automate prima di eseguire la migrazione?

Nr. Per ulteriori informazioni sulle linee guida per le licenze, vedi Quali sono i diritti di utilizzo di Microsoft Power Apps e Power Automate per le applicazioni Dynamics 365?

Alcune delle mie regole sono incomplete o parzialmente migrate. Cosa devo fare?

Puoi usare i dettagli del problema per correggere la regola nel client Web e quindi rieseguire la migrazione oppure correggere la regola migrata direttamente in Unified Interface.

Posso rieseguire lo strumento di migrazione per una regola migrata specifica?

Sì, puoi rieseguire lo strumento di migrazione per una regola migrata specifica in base ai seguenti criteri:

  • Per le regole incomplete o per quelle la cui migrazione non è riuscita: seleziona la stessa regola quando riesegui lo strumento di migrazione. Lo strumento sostituisce automaticamente la regola incompleta o non riuscita esistente con la regola appena migrata.
  • Per regole migrate correttamente: elimina la regola migrata in Unified Interface prima di eseguire nuovamente lo strumento di migrazione.

Una volta completata la migrazione, cosa succede ai record di contratti di servizio esistenti associati ai contratti di servizio legacy?

  • Se il contratto di servizio legacy viene disattivato dopo la migrazione: il timer continuerà a funzionare fino allo stato terminale per tali record di contratto di servizio. Tuttavia, le funzionalità Risolvi e Pausa non funzioneranno.
  • Se il contratto di servizio legacy è ancora nello stato Attivo: i record di contratto di servizio esistenti associati ai contratti di servizio legacy continueranno a funzionare come previsto.
  • Se desideri utilizzare i contratti di servizio creati nelle app Unified Interface su record esistenti: dovrai aggiornare manualmente il campo Contratto di servizio al contratto di servizio di Unified Interface o scrivere il plug-in per aggiornare i record. Ad esempio, la logica del plugin potrebbe essere Flusso moderno o Flusso di lavoro.

Per informazioni sulle regole o sui flussi migrati nella creazione automatica di record moderna, vedi Domande frequenti sulla creazione automatica di record moderna.

Problemi noti di conversione delle condizioni

Questa sezione descrive scenari chiave in cui le regole o gli elementi non completeranno correttamente la migrazione.

Nr. Al momento supportiamo solo un livello della gerarchia di entità correlate. Tali elementi o condizioni della regola possono essere migrati correttamente solo se rimuovi qualsiasi entità correlata nella clausola di gruppo prima di eseguire la migrazione. Se non intraprendi alcuna azione, la regola non riuscirà nel passaggio Controllo pre-migrazione. Se scegli di continuare con la migrazione, la regola avrà una condizione vuota per l'elemento correlato.

Visualizzazione del client Web pre-migrazione

Screenshot della visualizzazione del client Web di pre-migrazione di un elemento con entità correlate in una clausola di gruppo nidificata.

Legenda:

a. Titolo dell'elemento.

Visualizzazione di Unified Interface post-migrazione

Screenshot della visualizzazione di Unified Interface di post-migrazione dell'elemento con entità correlate in una clausola di gruppo nidificata.

Legenda:

2a. "_FailedMigration" viene aggiunto al titolo dell'elemento migrato.

2b. Lo stesso segnaposto standard, Data creazione uguale a 2200-01-01, viene aggiunto alla condizione.

Perché gli elementi o le condizioni della mia regola con un campo DateType che utilizza un operatore Not-On hanno esito negativo durante il controllo prima della migrazione e la migrazione effettiva?

L'operatore Not-On per il tipo di data Data non è supportato in Unified Interface. Pertanto, non è supportato come parte della migrazione. Per risolvere questo problema, puoi modificare gli elementi o le condizioni precedenti da {not-on selecteddate} in {selecteddate less than and selecteddate greater than} nel client Web prima di eseguire di nuovo lo strumento di migrazione per la regola corrispondente.

Esempio: campo DateType che utilizza un operatore Not-on

Visualizzazione del client Web pre-migrazione

Screenshot della visualizzazione del client Web di pre-migrazione di un elemento con un operatore Not-on per un campo DateType.

Legenda:

a. Titolo dell'elemento.

Visualizzazione di Unified Interface post-migrazione

Screenshot della visualizzazione di Unified Interface di post-migrazione di un elemento con un operatore Not-on per un campo DateType.

Legenda:

2a. "_FailedMigration" viene aggiunto al titolo dell'elemento migrato.

2b. La condizione Data creazione uguale a 2200-01-01 viene aggiunta alla condizione.

Perché i dati nel mio campo DateTime cambiano durante la migrazione?

Non esiste un campo temporale separato in Unified Interface. Quindi, il campo DateTime passerà da un controllo calendario a un campo di testo. L'input deve essere in un formato specifico come mostrato nel campo di testo nell'esempio seguente.

Esempio: campo DateTime

Visualizzazione del client Web pre-migrazione

Screenshot della visualizzazione del client Web di pre-migrazione in cui i campi DateTime sono rappresentati da controlli calendario.

Legenda:

a. Campo Data e ora di pre-migrazione.

b. Campo Solo data di pre-migrazione.

Visualizzazione di Unified Interface post-migrazione

Screenshot della visualizzazione di Unified Interface di post-migrazione in cui i campi DateTime sono rappresentati da campi di testo.

Legenda:

a. Campo Data e ora di post-migrazione.

b. Campo Solo data di post-migrazione.

Perché alcuni dei miei campi operatore sono vuoti in Unified Interface dopo la migrazione?

Per i tipi di dati di ricerca, solo gli operatori equal, not equal, null e not null sono supportati in Unified Interface e nello strumento di migrazione. Gli operatori Under e not-under non sono supportati in Unified Interface e pertanto non sono supportati nello strumento di migrazione. Qualsiasi condizione che abbia operatori under o not-under vengono convertiti come entità correlate dopo la migrazione. Vengono visualizzati come vuoti in Unified Interface e non possono essere modificati.

Esempio: campi operatore Under e not-under

Visualizzazione del client Web pre-migrazione

Screenshot della visualizzazione del client Web di pre-migrazione in cui una condizione utilizza gli operatori under.

Legenda:

a.Operatori Under.

Visualizzazione di Unified Interface post-migrazione

Screenshot della visualizzazione di Unified Interface di post-migrazione in cui una condizione ha un campo operatore vuoto.

Legenda:

b. Campo operatore vuoto.

Nota

Le seguenti limitazioni sono applicabili quando una condizione viene definita in Hub del servizio clienti:

  • Il controllo Selezione data e ora non è più disponibile nelle condizioni. Tuttavia, puoi comunque modificare la data e l'ora nel campo di testo.
  • Solo un livello della gerarchia di entità correlate è supportato. Tuttavia, puoi selezionare entità correlate nidificate nell'applicazione.
  • L'entità correlata in un gruppo della clausola and/or non è supportata.
  • L'operatore Not-on per il tipo di dati Data non è supportato.
  • Per il tipo di dati Ricerche, sono supportati solo gli operatori equal, not equal, null e not null. Gli operatori under e not-under non sono supportati.

Posso migrare di nuovo una regola dopo che è stata attivata?

  • Per le regole di creazione automatica dei record, sì. Puoi migrare di nuovo una regola attivata, ma devi prima disattivarla ed eliminarla da Unified Interface.
  • Per i contratti di servizio, no. Una volta attivata, una regola di contratto di servizio migrata viene collegata a un'altra entità (ad esempio un caso) o è in uso. Per impostazione predefinita, la migrazione di una regola attivata viene eseguita correttamente. Prima di poter migrare di nuovo una regola attivata, devi eliminarla. Tuttavia, esiste una limitazione per le regole di contratto di servizio di Unified Interface. Dopo che una regola è stata associata a un caso o a un'entità (ovvero, dopo che è stata attivata una volta), non puoi eliminarla, anche se è disattivata. Pertanto, la regola non può essere nuovamente migrata se è stata precedentemente attivata o applicata.

Posso migrare le regole per i contratti di servizio standard deprecate?

Nr. Lo strumento di migrazione supporta solo regole di contratto di servizio avanzate. Le regole di contratto di servizio standard sono state deprecate. Non sono più supportate in Unified Interface e pertanto non sono supportate nello strumento di migrazione. Per ulteriori informazioni, vai a SLA standard in Dynamics 365 Customer Service deprecati.

Problemi noti

Deprecazione della proprietà del canale

Se hai utilizzato proprietà del canale nella personalizzazione delle regole legacy, lo strumento di migrazione non eseguirà correttamente la migrazione di tali regole. Non esiste una soluzione generale che possa essere applicata per correggere questo divario per tutti gli utenti. La soluzione alternativa dipende in gran parte da come utilizzi le proprietà del canale nelle regole legacy.

Differenza di comportamento quando l'opzione "Crea casi per gli impegni associati a un caso risolto" è selezionata

  • Comportamento legacy: se l'e-mail include un caso correlato che è stato risolto dall'ora specificata, il caso risolto viene riattivato per impostazione predefinita. Non è richiesta nessuna personalizzazione.
  • Comportamento moderno: se l'e-mail include un caso correlato che è stato risolto dall'ora specificata, un nuovo caso viene creato per impostazione predefinita. La personalizzazione è necessaria per riattivare un caso esistente invece di crearne uno nuovo.

Differenza di comportamento quando l'opzione "Crea caso se per il cliente esiste un diritto valido" è selezionata

  • Comportamento legacy: se il mittente dell'e-mail non ha un diritto valido e l'e-mail ha un caso correlato, il caso correlato esistente viene aggiornato.
  • Comportamento moderno: se il mittente dell'e-mail non ha un diritto valido, non viene richiamato alcun flusso.

Divari di parità tra flussi di lavoro e flussi Power Automate (applicabili solo alla personalizzazione delle azioni degli elementi della regola)

  • Le espressioni "First not null" non possono essere migrate automaticamente. Tuttavia, la personalizzazione può essere applicata manualmente al flusso per la migrazione.
  • Il mapping del nome visualizzato di un record di ricerca a un campo stringa non può essere migrata automaticamente. Tuttavia, la personalizzazione può essere applicata manualmente al flusso per la migrazione.
  • I campi della parte attività utilizzati come campi di origine non sono supportati nel flusso.

Problemi noti relativi al flusso

Le regole migrate hanno un carattere @ aggiuntivo per i campi con tipo stringa @

Se il flusso di lavoro della regola di creazione automatica dei record legacy è personalizzato e contiene un carattere @ di testo normale in un campo stringa, verranno visualizzate due caratteri @ invece di uno durante la migrazione. Ad esempio, se aggiungi un indirizzo e-mail in testo normale nel campo della descrizione del caso, il carattere @ verrà trattato come un carattere speciale e migrato come @@.

Questo perché @ viene identificato come carattere speciale per qualsiasi espressione dinamica, ad esempio @triggerOutputs()?[body/_emailsender_value] nel flusso di migrazione.

La soluzione alternativa consiste nel rimuovere manualmente il carattere @ aggiuntivo nel flusso migrato.

La migrazione non supporta più elementi o condizioni con la stessa condizione "applicabile quando" all'interno dello stesso contratto di servizio

Nel client Web, è possibile definire più elementi che hanno la stessa condizione "applicabile quando" e diversi criteri di successo per un contratto di servizio. Tuttavia, la stessa funzionalità non è supportata in Unified Interface. Pertanto, durante la migrazione, non viene creato alcun elemento del contratto di servizio successivo di questo tipo che ha la stessa condizione "applicabile quando".

Gli screenshot seguenti illustrano lo scenario che non è supportato in Unified Interface. Le due condizioni "applicabile quando" mostrate hanno criteri di successo differenti.

Screenshot di una condizione

Screenshot della stessa condizione

Problemi con l'attributo del tipo partecipante all'impegno durante la conversione del flusso di lavoro a flusso

Un attributo del tipo di parte dell'attività assegnato a un altro campo del tipo di parte dell'attività non verranno migrati durante la conversione da flusso di lavoro a flusso, perché Power Automate non supporta attualmente questo scenario. I campi più comunemente interessati sono A, Da, CC e CCN nelle e-mail. Anche se la migrazione della regola riuscirà, il valore dei dati per tali campi di tipo parte di attività che si basano su un altro attributo di tipo parte di attività sarà vuoto dopo la migrazione.

Esempio attributi di tipo parte di attività

Visualizzazione del client Web pre-migrazione

Screenshot della visualizzazione del client Web di pre-migrazione in cui un flusso di lavoro ha due attributi di tipo parte di attività, Da e A.

Legenda:

a. Il campo Da è un campo di tipo parte di attività assegnato a un altro attributo di tipo parter di attività,{Bcc(Email)}. Sarà vuoto dopo la migrazione.

b. Il campo A verrà migrato.

Visualizzazione di Unified Interface post-migrazione

Screenshot della visualizzazione di Unified Interface di post-migrazione in cui il campo A è stato migrato.

Legenda:

b. Campo A.

I controlli "First Not Null" nelle espressioni in flussi di lavoro legacy non sono supportati durante la conversione da flusso di lavoro a flusso

Nei flussi di lavoro legacy, un campo di ricerca può essere mappato con più espressioni in cui controlli l'espressione "First not Null" e la assegni, come mostrato nell'esempio di client Web che segue. A causa di una limitazione nota nella progettazione di flussi di lavoro legacy, questo approccio non è supportato come parte della conversione da flusso di lavoro a flusso. Pertanto, il convertitore del flusso di lavoro assegna la prima espressione senza eseguire il controllo null. Rimuove quindi tutte le espressioni rimanenti, indipendentemente dal fatto che abbiano valori non nulli. Nell'esempio che segue, il flusso avrà solo Regarding(Email) nel campo Cliente in questo passaggio.

Esempio: espressioni "First Not Null"

Visualizzazione di pre-migrazione

Screenshot della visualizzazione del client Web per un campo Tema.

Legenda:

a.Visualizzazione del client Web: nel flusso di lavoro, il campo Cliente ha: {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}

In Unified Interface, il campo Cliente ha solo Regarding(Email), indipendentemente dal fatto che sia null o meno.

Importante

Se i problemi relativi allo strumento di migrazione persistono, contatta il tuo amministratore o il supporto tecnico Microsoft.

Vedi anche

Domande frequenti sulla creazione dei record automatica moderna

Migrare regole di creazione automatica dei record e SLA

Playbook per la migrazione di Dynamics 365 SLA e ARC