Preguntas frecuentes sobre a ferramenta de migración
Ferramenta de migración para regras de creación automática de rexistros e acordos de nivel de servizo (SLA)
Quen pode acceder ou executar a ferramenta de migración?
Os administradores e usuarios que teñan roles de xestor de RSE poden executar a ferramenta de migración.
As regras migradas están activadas automaticamente despois da migración?
Non. Debes activar manualmente as regras migradas despois de que se complete a migración.
Podo seguir usando as miñas regras antigas despois do prazo de obsolescencia?
Si. As regras legadas activas seguen a executarse despois do prazo de desactivación ata que se desactivan. Non obstante, a experiencia de edición e a compatibilidade detéñense despois da desuso.
Podo activar unha regra que teña un estado de migración "incompleta"?
Non. Unha regra migrada só se activa cando cambia a Marcar como completa a Si despois de revisar unha regra incompleta e solucionar calquera problema que estea presente. É entón cando a regra se considera migrada con éxito.
Desactivouse a regra antiga despois de migrar?
- Para a creación automática de rexistros, si. Cando activas unha regra de creación automática de rexistros migrada en Interface unificada, desactívase a regra antiga correspondente.
- Para os SLA, non. Cando activas unha regra SLA migrada en Interface unificada, a regra herdada correspondente permanece activa, porque as dúas regras poden coexistir.
Que significa un estado migratorio "incompleto"?
- Na sección Resumo: O proceso de migración global non puido completar correctamente a migración de todas as regras seleccionadas.
- Xunto a unha regra: A regra fallou ou non se puido migrar por completo (é dicir, non se puideron migrar un ou máis elementos ou condicións).
Onde podo atopar unha lista das regras parcialmente migradas rastrexadas na ferramenta de migración?
As regras que se migran parcialmente ou que se identifican como migradas incompletas non se consideran migradas totalmente. Polo tanto, fai un seguimento deles en Pendente na sección Resumo . Só as regras que completaron correctamente a migración se contabilizan en Migradas.
A ferramenta de migración admite formularios ou campos personalizados?
- Para a creación automática de rexistros, si. A ferramenta de migración admite entidades, campos, atributos e configuracións personalizados.
- Para os SLA, non. A ferramenta de migración non admite totalmente entidades, campos, atributos e configuracións personalizados. Para completar a migración, os usuarios deben modificar os fluxos de personalización, fluxos de traballo, complementos ou outro código personalizado existente nas entidades, campos, atributos e configuracións personalizados.
Necesito unha licenza separada para Power Automate antes de executar a migración?
Non. Para obter máis información sobre as directrices de licenzas, vai a Que son os dereitos de uso Microsoft Power Apps e Power Automate de aplicacións de Dynamics 365?
Algunhas das miñas regras están incompletas ou parcialmente migradas. Que debo facer?
Podes usar os detalles do problema para corrixir a regra no cliente web e despois executar de novo a migración ou corrixir a regra migrada directamente en Interface unificada.
Podo volver executar a ferramenta de migración para unha regra migrada específica?
Si, pode volver executar a ferramenta de migración para unha regra migrada específica, en función dos seguintes criterios:
- Para regras incompletas ou que non lograron a migración: Seleccione a mesma regra cando volva executar a ferramenta de migración. A ferramenta substitúe automaticamente a regra incompleta ou fallida existente pola regra recentemente migrada.
- Para as regras migradas correctamente: Elimine a regra migrada en Interface unificada antes de volver executar a ferramenta de migración.
Unha vez completada a migración, que ocorre cos rexistros de SLA existentes que están asociados aos SLA legados?
- Se o SLA herdado se desactiva despois da migración: O temporizador seguirá executándose ata que o estado do terminal destes rexistros de SLA. Non obstante, a función Resolver e Pausa non funcionará.
- Se o SLA heredado aínda está en estado Activo: Os rexistros SLA existentes que estean asociados aos SLA legados seguirán funcionando como se esperaba.
- Se queres utilizar os SLA creados nas aplicacións Interface unificada en rexistros existentes: Terá que actualizar manualmente o campo SLA a Interface unificada SLA ou escribir o complemento para actualizar os rexistros. Por exemplo, a lóxica do complemento pode ser Modern Flow ou Workflow.
Para obter información sobre as regras ou fluxos migrados na creación automática moderna de rexistros, vai a Preguntas frecuentes sobre a creación automática moderna de rexistros.
Problemas coñecidos de conversión de condicións
Esta sección describe escenarios clave nos que as regras ou os elementos non completarán correctamente a migración.
Se os elementos ou condicións da miña regra teñen entidades relacionadas dentro dunha cláusula de grupo aniñada (e/ou), migraranse á Interface unificada?
Non. Actualmente só admitimos un nivel da xerarquía de entidades relacionadas. Estes elementos ou condicións de regras só se poden migrar correctamente se elimina algunha entidade relacionada na cláusula do grupo antes de migrar. Se non realizas ningunha acción, a regra fallará durante a Comprobación previa á migración paso. Se decides continuar coa migración, a regra terá unha condición baleira para o elemento relacionado.
Exemplo: entidades relacionadas nunha cláusula de grupo aniñado
Vista de cliente web de premigración
Lenda:
a. O título do elemento.
Vista posterior á migración Interface unificada
Lenda:
2a. "_FailedMigration" engádese ao título do elemento migrado.
2b. O mesmo marcador de posición estándar, Creado en igual a 2200-01-01, engádese á condición.
Por que fallan os meus elementos ou condicións de regra cun campo DateType que usa un operador Not-On durante a comprobación previa á migración e a migración real?
O Non-On operador para o Data o tipo de datos non é compatible en Interface unificada. Polo tanto, non se admite como parte da migración. Para solucionar este problema, podes cambiar os elementos ou as condicións legais de {non-en data seleccionada} a {data seleccionada inferior a e data seleccionada superior a} no cliente web antes de volver executar a ferramenta de migración para a regra correspondente.
Exemplo: campo DateType que usa un operador Not-On
Vista de cliente web de premigración
Lenda:
a. O título do elemento.
Vista posterior á migración Interface unificada
Lenda:
2a. "_FailedMigration" engádese ao título do elemento migrado.
2b. Engádese á condición a condición Created On Equals 2200-01-01 .
Por que os datos do meu campo DateTime cambian durante a migración?
Non existe ningún campo de tempo separado en Interface unificada. Polo tanto, o campo DateTime pasará dun control de calendario a un campo de texto. A entrada debe estar nun formato específico, como se mostra no campo de texto do seguinte exemplo.
Exemplo: campo DateTime
Vista de cliente web de premigración
Lenda:
a. Campo de premigración Data e hora .
b. Premigración Campo de só data .
Vista posterior á migración Interface unificada
Lenda:
a. Campo Data e hora posterior á migración .
b. Campo Só data posmigración.
Por que algúns dos meus campos de operador están en branco en Interface unificada despois da migración?
Para os tipos de datos de busca, só os valores igual, non iguais, nulo e os operadores non nulos admítense en Interface unificada e na ferramenta de migración. Os operadores baixo e non baixo non son compatibles con Interface unificada e, polo tanto, non son compatibles coa ferramenta de migración. Calquera condición que teña operadores baixo ou non baixo tradúcese como entidades relacionadas despois da migración. Móstranse en branco en Interface unificada e non se poden editar.
Exemplo: campos de operador baixo e non baixo
Vista de cliente web de premigración
Lenda:
a.En operadores.
Vista posterior á migración Interface unificada
Lenda:
b. Campo de operador en branco.
Nota
As seguintes limitacións son aplicables cando se define unha condición en servizo de atención ao cliente Hub:
- A data e amp; O control do selector de tempo xa non está dispoñible nas condicións. Non obstante, aínda pode editar a data e a hora no campo de texto.
- Só se admite un nivel da xerarquía de entidades relacionadas. Non obstante, pode seleccionar entidades aniñadas e relacionadas na aplicación.
- Non se admite a entidade relacionada dentro dun grupo da cláusula e/ou.
- Non se admite o operador Non activado para o tipo de datos Data .
- Para o tipo de datos Búsquedas , só os igual, non iguais Admítense os operadores , null e non null . Os operadores under e non-under non son compatibles.
Podo migrar unha regra de novo despois de activala?
- Para as regras de creación automática de rexistros, si. Podes migrar unha regra activada de novo, pero primeiro debes desactivala e eliminala de Interface unificada.
- Para os SLA, non. Despois de activar unha regra de SLA migrada, está vinculada a outra entidade (como un caso) ou está en uso. Por defecto, unha regra activada foi migrada correctamente. Antes de poder migrar de novo unha regra activada, debes eliminala. Non obstante, hai unha limitación para as regras do SLA de Interface unificada. Despois de asociar unha regra a un caso ou entidade (é dicir, despois de que se activase unha vez), non podes eliminala, aínda que estea desactivada. Polo tanto, a regra non se pode migrar de novo se xa foi activada ou aplicada previamente.
Podo migrar regras de SLA estándar desfasadas?
Non. A ferramenta de migración só admite regras de SLA melloradas. As regras de SLA estándar quedaron en desuso. Xa non se admiten en Interface unificada e, polo tanto, non se admiten na ferramenta de migración. Para obter máis información, vaia a Os SLA estándar de Dynamics 365 Customer Service están obsoletos.
Problemas coñecidos
Reducción da propiedade da canle
Se utilizaches algunha propiedade da canle na personalización das regras antigas, a ferramenta de migración non migrará correctamente esas regras. Non hai ningunha solución xeral que se poida aplicar para corrixir esta lagoa para todos os usuarios. A solución depende en gran medida de como uses as propiedades da canle nas regras antigas.
Diferenza de comportamento cando se selecciona a opción "Crear casos para actividades asociadas a un caso resolto".
- Comportamento herdado: Se o correo electrónico ten un caso relacionado que foi resolto desde o momento especificado, o caso resolto reactivarase de forma predeterminada. Non se precisa personalización.
- Comportamento moderno: Se o correo electrónico ten un caso relacionado que se resolveu desde o momento especificado, créase un novo caso por defecto. A personalización é necesaria para reactivar un caso existente en lugar de crear un novo.
Diferenza de comportamento cando se selecciona a opción "Crear caso se existe un dereito válido para o cliente".
- Comportamento herdado: Se o remitente do correo electrónico non ten un dereito válido e o correo electrónico ten un caso relacionado, actualízase o caso relacionado existente.
- Comportamento moderno: Se o remitente do correo electrónico non ten un dereito válido, non se invoca ningún fluxo.
Brechas de paridade entre fluxos de traballo e Power Automate fluxos (aplicable só á personalización das accións dos elementos da regra)
- As expresións "Primeiro non nulas" non se poden migrar automaticamente. Non obstante, a personalización pódese aplicar manualmente ao fluxo para a migración.
- A asignación do nome para mostrar dun rexistro de busca a un campo de cadea non se pode migrar automaticamente. Non obstante, a personalización pódese aplicar manualmente ao fluxo para a migración.
- Os campos do grupo de actividade que se usan como campos de orixe non se admiten no fluxo.
Problemas coñecidos de fluxos
As regras migradas teñen un carácter extra para os campos con tipo de cadea @
Se o fluxo de traballo da regra de creación automática de rexistros heredado está personalizado e ten un carácter @ de texto simple nun campo de cadea, verá dous @, en lugar de un na migración. Por exemplo, se engade un enderezo de correo electrónico en texto plano no campo de descrición do caso, entón o carácter @ será tratado como un carácter especial e migrarase como @@.
Isto débese a que @ se identifica como un carácter especial para calquera expresión dinámica, como @triggerOutputs()?[body/_emailsender_value] no fluxo de migración.
A solución é eliminar manualmente o @ extra no fluxo migrado.
A migración non admite varios elementos ou condicións que teñan o mesmo "aplicable cando" dentro do mesmo SLA
No cliente web, pódense definir varios elementos que teñan a mesma condición de "aplicable cando" e diferentes criterios de éxito para un SLA. Non obstante, a mesma capacidade non se admite en Interface unificada. Polo tanto, durante a migración, non se crean elementos de SLA posteriores deste tipo que teñan a mesma condición "aplicable cando".
As seguintes capturas de pantalla mostran o escenario que non se admite en Interface unificada. As dúas condicións "aplicables cando" que se mostran teñen criterios de éxito diferentes.
Problemas de atributos de tipo partido da actividade durante a conversión de fluxo de traballo a fluxo
Non se migrará un atributo de tipo de grupo de actividade que se asignou a outro campo de tipo de grupo de actividade durante a conversión de fluxo de traballo a fluxo, porque Power Automate non admite este escenario actualmente. (Os campos máis afectados son A, De, CC, e CCO campos nos correos electrónicos.) Aínda que a migración da regra non fallará, o valor dos datos para tales campos de tipo partido da actividade que dependen outro atributo tipo de grupo de actividade estará en branco despois da migración.
Exemplo: Atributos de tipo grupo da actividade
Vista de cliente web de premigración
Lenda:
a. O campo De é un campo de tipo de grupo de actividade ao que se lle asigna outro atributo de tipo de grupo de actividade, {Cco(correo electrónico)}. Estará en branco despois da migración.
b. Migrarase o campo Para .
Vista posterior á migración Interface unificada
Lenda:
b.Para campo.
As verificacións "Primeiro non nulas" nas expresións dos fluxos de traballo legados non se admiten durante a conversión de fluxo de traballo a fluxo
Nos fluxos de traballo legados, pódese mapear un campo de busca con varias expresións nas que marca e asigna a expresión "Primeiro non nulo", como se mostra no exemplo do cliente web que segue. Debido a unha limitación coñecida no deseñador de fluxos de traballo heredado, este enfoque non se admite como parte da conversión de fluxo de traballo a fluxo. Polo tanto, o conversor de fluxo de traballo asigna a primeira expresión sen realizar a comprobación nula. A continuación, elimina todas as expresións restantes, independentemente de que teñan valores non nulos. No exemplo que segue, o fluxo só terá Referente a(Correo electrónico) no campo Cliente neste paso.
Exemplo: expresións "Primeiro non nulas".
Vista premigratoria
Lenda:
a.Vista web do cliente: No fluxo de traballo, o campo Cliente ten {Respecto (Correo electrónico); Contacto(Crear (caso)); Cliente(Crear (caso))}.
En Interface unificada, o Cliente campo ten só Sobre (correo electrónico), independentemente de que sexa nulo.
Importante
Se aínda tes problemas coa ferramenta de migración, ponte en contacto co teu administrador ou co soporte de Microsoft.
Consulte tamén
Preguntas frecuentes sobre creación automática de rexistros moderna