Compartir a través de


P+F de la herramienta de migración

Herramienta de migración para reglas de creación automática de registros y acuerdos de nivel de servicio (SLA)

¿Quién puede acceder o ejecutar la herramienta de migración?

Los administradores y usuarios que tienen funciones de administrador de CSR pueden ejecutar la herramienta de migración.

¿Las reglas migradas se activan automáticamente después de la migración?

No. Debe activar manualmente las reglas migradas después de finalizar la migración.

¿Puedo seguir usando mis reglas heredadas después de la fecha límite de obsolescencia?

Sí. Las reglas heredadas activas siguen funcionando después de la fecha límite de obsolescencia, hasta que se desactivan. Sin embargo, la experiencia de edición y la compatibilidad se detienen después de la obsolescencia.

¿Puedo activar una regla que tiene un estado de migración "incompleto"?

No. Una regla migrada solo se activa cuando cambia el conmutador Marcar como completado a después de revisar una regla incompleta y solucionar los problemas que presente. Es entonces cuando se considera que la regla se ha migrado correctamente.

¿La regla heredada se desactiva después de migrar?

  • Sí, para la creación automática de registros. Cuando activa una regla de creación automática de registros migrada en Interfaz unificada, la regla heredada correspondiente se desactivará.
  • No para SLA. Cuando activa una regla SLA migrada en Interfaz unificada, la regla heredada correspondiente se mantendrá activa porque pueden coexistir dos reglas.

¿Qué significa un estado de migración "incompleta"?

  • En la sección Resumen: el proceso global de migración no pudo completar correctamente la migración de todas las reglas seleccionadas.
  • Junto a una regla: la regla ha fallado o bien la regla no ha podido migrarse completamente (es decir, uno o más elementos o condiciones no han podido migrarse).

¿Dónde puedo encontrar una lista de reglas parcialmente migradas que se rastrean en la herramienta de migración?

Las reglas que se migran parcialmente o que se identifican como migradas de forma incompleta no se consideran migradas por completo. Por lo tanto, se siguen bajo Pendiente en la sección Resumen. Solo las reglas que completaron la migración correctamente se cuentan en Migradas.

¿La herramienta de migración admite formularios o campos personalizados?

  • Sí, para la creación automática de registros. La herramienta de migración admite entidades, campos, atributos y configuraciones personalizados.
  • No para SLA. La herramienta de migración no es totalmente compatible con entidades, campos, atributos y configuraciones personalizados. Para completar la migración, los usuarios deben modificar cualquier flujo de personalización, flujo de trabajo, complemento u otro código personalizado existente en las entidades, campos, atributos y configuraciones personalizados.

¿Necesito una licencia separada para Power Automate antes de ejecutar la migración?

No. Para obtener más información sobre las pautas de licencias, visite Qué son los derechos de uso de Microsoft Power Apps y Power Automate para aplicaciones de Dynamics 365?

Algunas de mis reglas están incompletas o parcialmente migradas. ¿Qué debo hacer?

Puede utilizar los detalles de la incidencia para arreglar la regla en el cliente web y luego volver a ejecutar la migración, o bien arreglar la regla migrada directamente en la Interfaz unificada.

¿Puedo volver a ejecutar la herramienta de migración para una regla migrada específica?

Sí, puede volver a ejecutar la herramienta de migración para una regla migrada específica según los criterios siguientes:

  • Para reglas incompletas o reglas en las que ha fallado la migración: seleccione la misma regla cuando vuelva a ejecutar la herramienta de migración. La herramienta sustituye automáticamente la regla incompleta o fallida existente por la regla recién migrada.
  • Para reglas migradas correctamente: elimine la regla migrada en Interfaz unificada antes de volver a ejecutar la herramienta de migración.

Una vez completada la migración, ¿qué sucede con los registros de SLA existentes asociados con los SLA heredados?

  • Si el SLA heredado se desactiva después de la migración: el temporizador seguirá funcionando hasta que se alcance el estado del terminal para dichos registros de SLA. Sin embargo, las funcionalidades Resolver y Pausa no funcionarán.
  • Si el SLA heredado todavía está en estado Activo: los registros de SLA existentes asociados con SLA heredados seguirán funcionando según lo previsto.
  • Si desea utilizar acuerdos de nivel de servicio creados en las aplicaciones Interfaz unificada en registros existentes: tendrá que actualizar manualmente el campo SLA a SLA de Interfaz unificada o escribir el complemento para actualizar los registros. Por ejemplo, la lógica del complemento podría ser Flujo moderno o Flujo de trabajo.

Para obtener información sobre las reglas o flujos migrados en la creación automática de registros moderna, vaya a Preguntas frecuentes acerca de la creación automática de registros moderna.

Problemas conocidos de conversión de condiciones

En esta sección se describen los escenarios clave en los que las reglas o elementos no completarán correctamente la migración.

No. Actualmente solo admitimos un nivel de la jerarquía de entidades relacionada. Tales elementos de regla o condiciones solo pueden migrarse con éxito si elimina cualquier entidad relacionada en la cláusula de grupo antes de migrar. Si no realiza ninguna acción, la regla fallará durante el paso Comprobación previa a la migración. Si elige continuar con la migración, la regla tendrá una condición vacía para el elemento relacionado.

Vista de cliente web previa a la migración

Captura de pantalla de la vista del cliente web previa a la migración de un elemento con entidades relacionadas en una cláusula de grupo anidada.

Leyenda:

a. El título del elemento.

Vista de Interfaz unificada posterior a la migración

Captura de pantalla de la vista de Interfaz unificada posterior a la migración de un elemento con entidades relacionadas en una cláusula de grupo anidada.

Leyenda:

2a. "_FailedMigration" se añade al título del elemento migrado.

2b. El mismo marcador de posición estándar Creado en es igual a 2200-01-01 se agrega a la condición.

¿Por qué los elementos o condiciones de mi regla con un campo DateType que utiliza un operador "No el" fallan durante la verificación previa a la migración y la migración real?

El operador No el para el tipo de datos Fecha no es compatible con la Interfaz unificada. Por lo tanto, no se admite como parte de la migración. Para solucionar este problema, puede cambiar los elementos o condiciones heredados de {not-on selecteddate} a {selecteddate less than and selecteddate greater than} en el cliente web antes de volver a ejecutar la herramienta de migración para la regla correspondiente.

Ejemplo: campo DateType que utiliza un operador No-el

Vista de cliente web previa a la migración

Captura de pantalla de la vista del cliente web previa a la migración de un elemento con un operador No-el activado para un campo DateType.

Leyenda:

a. El título del elemento.

Vista de Interfaz unificada posterior a la migración

Captura de pantalla de la vista de Interfaz unificada posterior a la migración del elemento con un operador No-el activado para un campo DateType.

Leyenda:

2a. "_FailedMigration" se añade al título del elemento migrado.

2b. La condición Creado el es igual a 2200-01-01 se agrega a la condición.

¿Por qué cambian los datos de mi campo DateTime durante la migración?

No existe ningún campo de hora separado en la Interfaz unificada. Por lo tanto, el campo DateTime cambiará de un control de calendario a un campo de texto. La entrada debe tener un formato específico, como se muestra en el campo de texto del siguiente ejemplo.

Ejemplo: campo DateTime

Vista de cliente web previa a la migración

Captura de pantalla de la vista del cliente web previa a la migración donde los campos de DateTime están representados por controles de calendario.

Leyenda:

a. Campo de Fecha y hora previa a la migración.

b. Campo de Solo fecha previa a la migración.

Vista de Interfaz unificada posterior a la migración

Captura de pantalla de la vista Interfaz unificada posterior a la migración donde los campos de fecha y hora están representados por campos de texto.

Leyenda:

a. Campo de Fecha y hora posterior a la migración.

b. Campo de Solo fecha posterior a la migración.

¿Por qué algunos de los campos de mi operador están en blanco en Interfaz unificada después de la migración?

Para los tipos de datos de búsqueda, solo los operadores igual, no es igual, nulo y no nulo son compatibles con Interfaz unificada y son compatibles con la herramienta de migración. Los operadores menor que y no menor que no son compatibles con Interfaz unificada y, por lo tanto, no son compatibles con la herramienta de migración. Cualquier condición que tenga operadores en o no pertenece a se traduce como entidades relacionadas después de la migración. Se muestran en blanco en Interfaz unificada y no se pueden editar.

Ejemplo: campos de operador En y No pertenece a

Vista de cliente web previa a la migración

Captura de pantalla de la vista del cliente web previa a la migración donde utiliza una condición utiliza los operadores En.

Leyenda:

a. Operadores En.

Vista de Interfaz unificada posterior a la migración

Captura de pantalla de la vista Interfaz unificada posterior a la migración donde una condición tiene un campo de operador en blanco.

Leyenda:

b. Campo de operador en blanco.

Nota

Las siguientes limitaciones son aplicables al definir una condición en el Centro de servicio al cliente:

  • El control del selector Fecha y Hora ya no está disponible en las condiciones. Sin embargo, aún puede editar la fecha y la hora en el campo de texto.
  • Solo se admite un nivel de la jerarquía de entidades relacionadas. Sin embargo, puede seleccionar entidades anidadas y relacionadas en la aplicación.
  • La entidad relacionada dentro de un grupo de la cláusula "y/o" no es compatible.
  • No se admite el operador No-el para el tipo de datos Fecha.
  • Para el tipo de datos Búsquedas, solo se admiten los operadores igual, no es igual, nulo y no es nulo. Los operadores En y No-el no se admiten.

¿Puedo migrar una regla nuevamente después de que se haya activado?

  • Sí, para reglas de creación automática de registros. Puede migrar una regla activada nuevamente, pero primero debe desactivarla y eliminarla de la Interfaz unificada.
  • No para SLA. Una vez que se activa una regla de SLA migrada, se vincula a otra entidad (como un caso o está en uso). De forma predeterminada, una regla activada se ha migrado correctamente. Antes de poder volver a migrar una regla activada, debe eliminarla. Sin embargo, existe una limitación para las reglas de SLA de Interfaz unificada. Después de asociar una regla con un caso o entidad (es decir, después de que se haya activado una vez), no puede eliminarla, incluso si está desactivada. Por tanto, la regla no se puede volver a migrar si se ha activado o aplicado previamente.

¿Puedo migrar reglas de SLA estándar obsoletas?

No. La herramienta de migración solo admite reglas de SLA mejoradas. Las reglas estándar de SLA han quedado obsoletas. Ya no se admiten en la Interfaz unificada y, por tanto, tampoco en la herramienta de migración. Para obtener más información, visite Los SLA estándar en Dynamics 365 Customer Service han quedado obsoletos.

Problemas conocidos

Obsolescencia de propiedad de canal

Si ha utilizado alguna propiedad de canal en la personalización de reglas heredadas, la herramienta de migración no migrará correctamente esas reglas. No existe una solución alternativa general que pueda aplicarse para solucionar esta brecha para todos los usuarios. La solución alternativa depende en gran medida de cómo utilice las propiedades del canal en las reglas heredadas.

Diferencia de comportamiento cuando se selecciona la opción "Crear casos para actividades asociadas a un caso resuelto"

  • Comportamiento heredado: si el correo electrónico tiene un caso relacionado que se ha resuelto desde el momento especificado, el caso resuelto se reactiva de forma predeterminada. No es necesaria ninguna personalización.
  • Comportamiento moderno: si el correo electrónico tiene un caso relacionado que se ha resuelto desde el momento especificado, se crea un nuevo caso de forma predeterminada. Se requiere personalización para reactivar un caso existente en lugar de crear un nuevo caso.

Diferencia de comportamiento cuando se selecciona la opción "Crear caso si existe un derecho válido para el cliente"

  • Comportamiento heredado: si el remitente del correo electrónico no tiene un derecho válido y el correo electrónico tiene un caso relacionado, el caso relacionado existente se actualiza.
  • Comportamiento moderno: si el remitente del correo electrónico no tiene un derecho válido, no se invoca ningún flujo.

Brechas de paridad entre flujos de trabajo y flujos de Power Automate (aplicable solo a la personalización de acciones de elementos de reglas)

  • Las expresiones "Primero no nulo" no se pueden migrar automáticamente. Sin embargo, la personalización se puede aplicar manualmente al flujo de la migración.
  • La asignación del nombre de un registro de búsqueda a un campo de cadena no se puede migrar automáticamente. Sin embargo, la personalización se puede aplicar manualmente al flujo de la migración.
  • Los campos de parte de actividad que se utilizan como campos de origen no se admiten en el flujo.

Problemas conocidos de Flow

Las reglas migradas tienen un carácter @ adicional para los campos con tipo de cadena @

Si el flujo de trabajo de la regla de creación automática de registros heredada está personalizado y tiene un carácter @ de texto sin formato en un campo de cadena, verá dos @, en lugar de uno en la migración. Por ejemplo, si agrega una dirección de correo electrónico en texto sin formato en el campo de descripción del caso, el carácter @ se tratará como un carácter especial y se migrará como @@.

Esto se debe a que @ se identifica como un carácter especial para cualquier expresión dinámica, como @triggerOutputs()?[body/_emailsender_value] en el flujo de migración.

La solución alternativa es eliminar manualmente el @ adicional en el flujo migrado.

La migración no admite varios elementos o condiciones que tengan el mismo "aplicable cuando" en el mismo SLA

En el cliente web, se pueden definir varios elementos con la misma condición "aplicable cuando" y diferentes criterios de éxito para un SLA. Sin embargo, la misma capacidad no se admite en Interfaz unificada. Por lo tanto, durante la migración, no se crean elementos SLA posteriores de este tipo que tengan la misma condición de "aplicable cuando".

Las siguientes capturas de pantalla muestran el escenario que no es compatible con Interfaz unificada. Las dos condiciones "aplicable cuando" que se muestran tienen criterios de éxito diferentes.

Captura de pantalla de una condición

Captura de pantalla de la misma condición

Problemas de atributos de tipo de grupo de actividad durante el flujo de trabajo a la conversión de Flow

Un atributo de tipo de parte de actividad que esté asignado a otro campo de tipo de parte de actividad no se migrará durante la conversión de flujo de trabajo a flujo, porque Power Automate no admite actualmente este escenario. (Los campos más comúnmente afectados son los campos Para, De, CC y CCO en correos electrónicos.) Aunque la migración de la regla no fallará, el valor de los datos para dichos campos de tipo parte de actividad que dependen de otro atributo de tipo de parte de actividad estará en blanco después de la migración.

Ejemplo: Atributos de tipo parte de actividad

Vista de cliente web previa a la migración

Captura de pantalla de la vista del cliente web previa a la migración donde un flujo de trabajo tiene dos atributos de tipo de parte de actividad, Desde y Hasta.

Leyenda:

a. El campo De es un campo de tipo de entidad de actividad al que se le asigna otro atributo de tipo de entidad de actividad {Bcc(Email)}. Estará en blanco después de la migración.

b. El campo Para se migrará.

Vista de Interfaz unificada posterior a la migración

Captura de pantalla de la vista Interfaz unificada posterior a la migración a la que se ha migrado el campo Para.

Leyenda:

b. Campo Para.

Las comprobaciones "Primero no nulo" en expresiones de flujos de trabajo heredados no son compatibles durante la conversión de flujo de trabajo a flujo de trabajo

En los flujos de trabajo heredados, un campo de búsqueda se puede asignar a múltiples expresiones donde usted verifica y asigna la expresión "Primero no nulo", como se muestra en el ejemplo de cliente web que aparece a continuación. Debido a una limitación conocida en el diseñador de flujos de trabajo heredado, este enfoque no se admite como parte de la conversión de flujo de trabajo a flujo. Por lo tanto, el convertidor de flujo de trabajo asigna la primera expresión sin realizar la verificación nula. Luego elimina todas las expresiones restantes, independientemente de si tienen valores no nulos. En el ejemplo que sigue, el flujo solo tendrá Regarding(Email) en el campo Cliente en este paso.

Ejemplo: expresiones "Primero no nulo"

Vista previa a la migración

Captura de pantalla de la vista del cliente web para un campo Referente a.

Leyenda:

a.Vista de cliente web: en el flujo de trabajo, el campo Cliente tiene {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.

En la Interfaz unificada, el campo Cliente solo tiene Regarding(Email), independientemente de si es nulo.

Importante

Si aún tiene problemas con la herramienta de migración, comuníquese con su administrador o con el soporte técnico de Microsoft.

Consulte también

Preguntas frecuentes sobre la creación automática moderna de registros

Migrar reglas de creación automática de registros y SLA

SLA de Dynamics 365 y Cuaderno de estrategias de migración de ARC