Planificar y probar en sandbox su migración

Tipos de artículos

Al migrar de Classic a Lightning Knowledge, los tipos de artículo se asignan a nuevos tipos de registros con el mismo nombre que los tipos de artículo. Se asignan al nombre de API , no el nombre de etiqueta. Realice las siguientes comprobaciones antes de continuar a la migración y sea consciente de estas limitaciones.

• Implemente tipos de artículo sin implementar que desee migrar.
• Identifique y elimine de forma permanente tipos de artículo que no necesite.
• Cambie configuraciones de metadatos en tipos de artículo de Knowledge en Configuración. Por ejemplo, agregue un tipo artículo, elimine un tipo de artículo, cambie ajustes en un tipo de artículo, o cambie el acceso de perfil a tipos de artículo.
• Cambie la configuración de Tipo de artículo predeterminado a Ninguno.

Elimine las siguientes dependencias. Cuando la herramienta de migración desactiva tipos de artículo antiguos, estos objetos no siempre se eliminan, provocando el fallo de la migración.

• Entidades resumidas por otras entidades
• Trabajos de informes que hacen referencia a una definición de entidad personalizada
• Tipos de artículos a los que se hace referencia por la configuración de Contribución de agente
• Tipos de artículos a los que se hace referencia por la configuración de Promoción de respuestas
• Objetos personalizados utilizados por reglas de coincidencia
• Tipos de artículo utilizados por una regla de duplicados
• Eliminaciones gestionadas que apuntan al tipo de artículo
• Tipos de artículo con campos personalizados secundarios que no se pueden eliminar desde otros paquetes gestionados
• Tipos de artículo a los que hacen referencia otras funciones, como clases de Apex o flujos de datos

La activación de Lightning Knowledge se bloquea si cualquier paquete creado en la organización actual contiene un tipo de artículo. Para activar Lightning Knowledge, elimine tipos de artículo de paquetes creados en la organización actual.

Formatos de página

Para dar a sus usuarios una excelente experiencia de formato y acceder a los campos apropiados, ajuste los formatos de página. Puede asignar diferentes formatos de página por tipo de registro y perfil de usuario tras la migración. Asegúrese de que están configurados correctamente durante la migración. Antes de iniciar la migración, elimine los formatos de página que no necesita.

Consideraciones sobre los campos

Al asignar campos desde múltiples tipos de artículo en un solo tipo de registro, tenga en cuenta estas consideraciones.

• Los campos de fórmulas no migran. Tras la migración, cree campos de fórmula en el objeto Knowledge, y revise las fórmulas que hacen referencia al nuevo objeto.
• Las dependencias de campos no migran. La herramienta de migración migra los campos. Sin embargo, no migra sus parámetros de dependencia de campo.
• Las listas de selección y las listas de selección múltiples se asignan únicamente si tienen los mismos valores de lista de selección, los mismos valores desactivados o la misma lista de selección global. No puede migrar listas de selección dependientes. Las opciones de lista de selección migran, pero la asignación entre ellas no. Restablece estos tras la migración. Del mismo modo, los valores predeterminados para listas de selección y las casillas de verificación no migran a Lightning Knowledge.
  

  Sugerencia Una organización puede tener dos campos de lista de selección A y B. A es la lista de selección de control y B es la lista de selección dependiente. La herramienta de migración migra tanto A como B, pero se convierten en listas de selección independientes y debe volver a definir los parámetros de dependencia de campo entre ellas.
• Cuando asigne campos a otros campos, seleccione el campo de destino desde una lista de selección que establece cuál es el campo principal.
• Si el tamaño del campo se reduce antes de la migración pero los artículos tienen más caracteres que antes de la reducción del tamaño de campo, todo el texto podría mostrarse en Classic. Sin embargo, después de la migración, el tamaño del campo se trunca en el nuevo objeto, lo que significa que los caracteres adicionales no se muestran. Por ejemplo, si un campo con 500 caracteres aumenta a 1.000 en Classic, puede haber 1.000 caracteres en el campo pero solo 500 de ellos se muestran en Lightning.
• Los indicadores de campo requerido no migran. Por lo tanto, se deben reformular los campos requeridos tras la migración por cada organización ya que residen todos en la misma tabla. Es mejor gestionar campos requeridos a través de formatos de página o reglas de validación, a menos que sean realmente requeridos para todos los registros en todos los tipos de registro.
• Los campos migrados tienen el nombre “Tipo Artículo_Nombre Campo”. Esta convención elimina conflictos de nombre de campo.
• Los campos eliminados (datos eliminados temporalmente que se mantienen durante 30 días) no migran.

Personalizaciones y paquetes gestionados (o no gestionados)

Inspeccione elementos personalizados antes y tras la migración para asegurarse de que pasaron al nuevo objeto Knowledge. A veces se descomponen, por lo que prepárese para evaluar este aspecto de la organización al realizar la migración de sandbox (antes de la migración en producción). Tras la migración, ajuste los elementos personalizados que hacen referencia a un Tipo de artículo para que apunten al nuevo objeto Knowledge.

Desinstale todos los paquetes que incluyan un tipo de artículo. Si no desinstala esos paquetes, no podrá activar Lightning Knowledge ni iniciar la Herramienta de migración de Lightning Knowledge.

La Herramienta de migración de Lightning Knowledge no funciona para Developer Edition si define un espacio de nombres para el empaquetado.

Éstos son algunos ejemplos de personalizaciones a tener en cuenta en sus evaluaciones tras la migración.

• SOQL que consulta el nombre de entidad preciso
• Páginas de Visualforce que hacen referencia a tipos de artículo antiguos
• Código que utiliza conjuntos de campos
• Código de Apex que hace referencia a tipos de artículo antiguos
• Código personalizado utilizando llamadas de API que hacen referencia a tipos de artículo
• Lógica de aplicación de cliente como código de API actual
• Paquetes de AppExchange
• Reglas de validación
• CRUD (por tipo de artículo)
• Aplicaciones que utilizan las API de metadatos en conjuntos de campo o formatos compactos

Importante Para organizaciones con múltiples tipos de artículos, actualice estas personalizaciones para que hagan referencia al nuevo objeto Knowledge tras comenzar la migración y antes de seleccionar Aceptar. Si algunos datos no migraron y desea realizar una pausa en la migración, actualice estas personalizaciones para que hagan referencia a tipos de artículo antiguos antes de seleccionar Deshacer. En caso contrario, el nuevo objeto Knowledge no siempre se elimina después de deshacer la migración.