Los campos de datos son la base de todo help desk. Definen la estructura de tickets, flujos, informes y métricas de equipo. Al migrar de sistema, mapear bien los campos es tan vital como mover los datos.
Dicho de otro modo, Help Desk Migration hace que el mapeo y la migración de datos sean procesos más seguros y fáciles — siempre que sigas las reglas.
En esta guía práctica, veremos los principios clave.
Campos Estándar vs. Personalizados en Help Desk Migration
Todo help desk se basa en campos. Algunos vienen con el sistema; otros los crea usted.
Campos predeterminados
Por ejemplo, en Zendesk, incluyen: Solicitante, Agente, CC, Asunto, Descripción, Estado, Tipo, Prioridad y Etiquetas.
Estos forman la base estructural de cada ticket.
Campos personalizados
Pueden ser: ID de pedido, Plan de suscripción, Tipo de producto, Nivel de SLA, etc.
Capturan datos específicos de su flujo y potencian la automatización e informes.
Help Desk Migration migra ambos tipos.
Como son el esqueleto de sus datos, es vital unirlos bien al migrar. Aquí es donde surgen las dudas del cliente.
Por qué el mapeo de datos genera tanta ansiedad
Cuando los clientes utilizan Help Desk Migration, la mayoría de los riesgos help desk migration surgen durante el mapeo de campo.
Los usuarios pueden experimentar:
- Pérdida de granularidad del campo (por ejemplo, un campo de selección múltiple se convierte en un campo de selección única y conserva solo un valor)
- Estados de tickets modificados o distorsionados
- Billetes perdidos
- Usuarios u organizaciones duplicados
- Desencadenantes de automatización no deseados
¿La buena noticia? Todo esto, desde disparadores erróneos hasta pérdida de datos, se controla con una configuración correcta y preparación previa. Esto requiere entender qué puede y qué no puede hacer la herramienta.
Empecemos por lo básico: ¿Qué objetos migra Help Desk Migration?
¿Qué objetos se pueden mapear en Help Desk Migration?
Help Desk Migration permite transferir campos estándar y personalizados de tickets, problemas, cambios, contactos, empresas, artículos y tareas de PM entre plataformas.
Tipos de campos admitidos en Help Desk Migration
La herramienta migra todos los tipos de campos principales:
- Campos con opciones predefinidas, como menús desplegables, casillas de verificación y opciones de selección múltiple
(p. ej., Tipo de problema, Región, Nivel de SLA) . En el Asistente de migración, se muestran como campos desplegables. - Texto/cadena . Campos de entrada de formato libre para texto corto o largo.
- Numérico. Campos que almacenan números como ID, cantidades o referencias internas.
- Fecha. Campos que almacenan fechas del calendario (por ejemplo, fecha de renovación, inicio del contrato, fecha límite personalizada).
- Campos de expresiones regulares. Campos validados por una regla basada en patrones. Por ejemplo, un campo que solo acepta un ID de pedido con el formato correcto, como ORD-12345. Estos campos se muestran para su mapeo entre plataformas, pero sus datos solo se migran para Zendesk y Pylon , donde la lógica de patrones es totalmente compatible.
- Campos de fórmula. Campos cuyos valores se calculan automáticamente a partir de otros campos. Por ejemplo, un campo que calcula el coste total a partir de la cantidad × precio, o una puntuación de prioridad derivada de varias entradas. En algunas plataformas, los campos de fórmula se pueden asignar como un tipo de campo. La migración del valor calculado real depende de cómo la plataforma almacene esos datos.
El primer paso para mapear correctamente estos tipos de campos de la mesa de ayuda comienza con una regla importante.
Regla de oro: Mapear campos por su tipo
Una migración fiel inicia con la consistencia del tipo de campo, Al vincular campos estándar o propios, asegure que los tipos coincidan entre origen y destino.
- Un campo de texto solo se puede asignar a un campo de texto.
- Un campo numérico debe asignarse a un campo numérico.
- Un campo desplegable debe conectarse a un campo desplegable con valores correspondientes.
- También se puede asignar un campo numérico o un campo de fecha a un campo de texto en el lado de destino.
- Etcétera.
Si los tipos no se alinean, es posible que los datos no se migren correctamente o pierdan estructura.
Campos de selección: Desplegables, Multiselección y Checkbox
La asignación de campos desplegables en Help Desk Migration requiere alinear los valores de las opciones individuales, no solo el nombre del campo. Esta regla se aplica a todos los campos de selección.
En otras palabras, no basta con conectar "Tipo de problema" con "Categoría". Cada opción dentro del campo debe corresponder a su equivalente exacto (por ejemplo, "Incidente" con "Incidente" o "Problema" con "Problema").
Además, cuide la migración de campos de Selección Única y Multiselección en el Asistente. Las uniones Única > Única y Única > Multi funcionan bien; pero en Multi > Única, solo se migrará el primer valor seleccionado.
Gestión de opciones no mapeadas en campos de selección
A veces, los valores de campo no se pueden migrar porque no coinciden exactamente entre los sistemas de origen y destino.
Si es necesario, nuestro equipo ajustará las configuraciones para garantizar que cada valor llegue donde debería.
Campos que no se migran
Los campos desplegables sin opciones no aparecerán en la interfaz de mapeo; este es un problema común con este tipo de datos.
Además, los valores de desplegables eliminados no se muestran. Por ejemplo, un ticket puede conservar un valor histórico, pero si este se borró de la lista de opciones actual, no figurará al mapear. En esos casos, el sistema vincula esos registros automáticamente al valor por defecto en el destino.
Al no haber valores que alinear, el sistema los excluye de forma automática de la interfaz de usuario de mapeo.
Crear campos personalizados antes de la migración
Los campos personalizados deben existir en el sistema de destino antes de poder mapearlos.
Si un campo no existe en el lado del destino, no habrá nada a lo cual conectarlo y los datos no se transferirán bien. Por eso, preparar los campos personalizados al inicio del proceso es un paso crítico en toda migración.
Pero existen algunas excepciones.
Lógica de creación de campos propios según plataforma
En la mayoría de los casos, los clientes necesitan crear campos antes de la migración, directamente en la mesa de ayuda de destino.
Asegúrese de seguir estas reglas de mapeo de campos específicas de la plataforma:
Freshdesk
Los campos seleccionados se crean como custom_dropdown.
Zendesk
El sistema verifica si el campo debe ser un etiquetador (selección única) o de selección múltiple y crea uno en consecuencia.
Intercom
Los campos seleccionados se crean con la lista de tipos.
Jira Service Management
El sistema determina si el campo debe ser de tipo selección o selección múltiple según la estructura de origen.
Además, si un menú desplegable contiene cientos o miles de opciones, crearlo mediante el asistente puede generar un error. En algunos casos, el campo se crea, pero no se añade automáticamente al proyecto, por lo que un ingeniero debe verificarlo y ajustarlo.
Intercom
La API limita los campos desplegables a 250 valores, pero la interfaz puede admitir campos con más.
Limitaciones clave para cualquier plataforma
Un cliente no puede crear campos duplicados a través del Wizard, y los campos desplegables conservan las mismas opciones que en el sistema de origen.
Límites al mapear campos de Contactos y Empresas
Help Desk Migration admite la transferencia de campos personalizados para contactos y empresas en pares de migración seleccionados.
Para comprobar si la migración de campos de empresa y contacto es compatible en su caso, navegue a Entidad → Datos.
Si ve “Describir - 1” junto a los campos personalizados de contacto o empresa, significa que se pueden migrar dentro del flujo automatizado estándar.
De lo contrario, esos campos no se transferirán automáticamente, incluso si ya existen campos idénticos en la plataforma de destino. En tales casos, nuestro equipo técnico ofrece una gestión personalizada.
Desde el lado del cliente, si la migración de campos propios de contacto y empresa no es compatible con su par de plataformas, solo verá los campos estándar para mapear (como Nombre, Email, etc.).
Migración de campos dependientes multinivel
Un campo multinivel (también llamado campo anidado o dependiente) contiene varias capas de opciones. La elección realizada en el primer nivel determina qué opciones estarán disponibles en el siguiente.
Un ejemplo sencillo es un campo de dirección:
Nivel 1 → País
Nivel 2 → Ciudad (filtrado por país)
Nivel 3 → Calle (filtrado por ciudad)
Cada selección limita el siguiente conjunto de opciones.
Por qué los campos multinivel dan problemas
Los campos de varios niveles a menudo crean desafíos de migración cuando la estructura no se replica correctamente en el sistema de destino.
Cómo Help Desk Migration gestiona campos multinivel cuando el objetivo carece de soporte
Si el origen tiene campos multinivel pero el destino no admite campos dependientes, existen soluciones prácticas.
Opción 1: Dividir un campo multinivel en varios desplegables
Si el sistema de origen tiene un campo de varios niveles pero el de destino no, el cliente puede crear campos desplegables separados en el de destino, uno para cada nivel.
Por ejemplo:
- País (menú desplegable)
- Ciudad (desplegable)
- Calle (desplegable)
Dentro de esta configuración, las opciones del mismo campo de origen se asignan a múltiples campos de destino, alineados según sus respectivos niveles.
Opción 2: Mapear varios campos en uno solo de multinivel
Si el sistema de origen tiene campos desplegables separados (por ejemplo, País, Ciudad, Calle), pero el sistema de destino admite un solo campo de varios niveles, es posible realizar un mapeo personalizado.
En este caso nuestro equipo puede configurar el mapeo.
El cliente debe proporcionar un archivo de mapeo estructurado que guíe cómo deben combinarse los niveles.
Los campos multinivel requieren especial atención porque almacenan no solo valores, sino también relaciones estructuradas entre ellos. Una preparación adecuada garantiza que esta estructura no se pierda durante la migración.
Reglas de salto, campos obligatorios y valores por defecto
El mapeo de campos no se trata solo de correlacionarlos. También implica controlar qué datos aparecen en el sistema de destino, de forma consistente y a escala.
Omitir este campo
Disponible sólo para campos no obligatorios.
Esta opción deja el campo de destino vacío en todos los tickets migrados, independientemente del valor de origen.
Utilice Omitir este campo en las migraciones cuando:
- El campo existe en el destino pero ya no es relevante.
- El campo es opcional y se puede dejar en blanco.
Valor por defecto
Esta opción establece un valor fijo para un campo desplegable en todos los tickets migrados.
Por ejemplo, si configura Tipo → Problema, cada ticket migrado tendrá “Problema” seleccionado en el campo Tipo, sin importar el valor original.
La opción de valor de campo predeterminado es útil cuando:
- Estandarización de datos históricos.
- Pasando a una estructura de campo simplificada.
- Aplicando un nuevo modelo de categorización.
Usar para valores predeterminados o vacíos
Disponible sólo cuando se asignan campos obligatorios.
Esta opción llena un campo de destino obligatorio de manera predeterminada solo si el campo de origen asignado está vacío en un ticket específico.
Esto significa:
- Si el valor de origen existe → migra normalmente.
- Si el valor de origen está vacío → se aplica el valor de reserva seleccionado.
Esto evita errores de migración y al mismo tiempo preserva los datos reales donde existan.
Sin completar
Disponible para mapeo de campo opcional.
Si se seleccionan ciertos valores mapeados en la fuente, esta opción deja el campo de destino vacío.
Es útil cuando:
- Algunos valores de origen ya no son relevantes.
- Desea excluir intencionalmente categorías específicas de la migración.
- El campo es opcional y debe permanecer en blanco bajo ciertas condiciones.
Estos controles le brindan la flexibilidad de refinar y estandarizar los datos durante el traslado.
Errores comunes de mapeo y cómo corregirlos
La mayoría de los problemas de mapeo de campos ocurren por dos razones: campos duplicados en el sistema de destino o condiciones de campo requeridas que bloquean la creación o el cierre de tickets.
Nombre duplicado
El error de campo duplicado aparece cuando el sistema de destino ya contiene un campo con el mismo nombre.
Incluso si no lo ves inmediatamente, el campo puede:
- Existir pero estar inactivo
- Pertenecer a un proyecto diferente (en sistemas basados en proyectos)
- Estar oculto por la configuración
Cómo solucionarlo:
- Compruebe si el campo ya existe en el destino.
- Activar o reutilizar el campo existente en lugar de crear uno nuevo.
- En plataformas basadas en proyectos, asegúrese de que el campo se agregue al proyecto correcto.
Obligatorio = Campo faltante
Este error ocurre cuando un campo obligatorio en el sistema de destino no recibe ningún valor durante la migración.
Es posible que se requiera un campo:
- Para la creación de tickets
- Para el cierre de tickets
- Debido a reglas o condiciones específicas
Por ejemplo, un sistema podría impedir el cierre de un ticket si un campo obligatorio (p. ej., Tipo de resolución) está vacío. Estos requisitos pueden configurarse directamente en la configuración del campo o controlarse mediante las condiciones del flujo de trabajo.
A veces, un campo puede no aparecer como obligatorio durante la asignación porque las reglas condicionales solo se aplican en ciertos casos. Sin embargo, una vez ejecutada la migración, estas reglas pueden bloquear las actualizaciones de tickets si el campo está vacío.
Cómo solucionar el error de campo obligatorio:
- Asegúrese de que todos los campos obligatorios estén asignados.
- Utilice “Valor predeterminado” o “Usar para valores predeterminados o vacíos” para evitar que los campos obligatorios estén vacíos.
- Revise las condiciones del campo y las reglas del flujo de trabajo antes de iniciar la Full Migration.
El conocimiento de estos dos tipos de errores ayuda a evitar interrupciones y mantiene la migración fluida de principio a fin.
Demo Migration: Validación real (no como teoría)
Una Demo Migration le permite ver cómo actúan sus reglas antes de lanzar la Full Migration.
Demo gratuita ilimitada
La migra 20 tickets aleatorios con todos los registros relacionados, junto con 20 artículos de la base de conocimientos. A continuación, genera un informe que detalla qué registros se migraron correctamente y cuáles no.
Puedes ejecutar la demostración ilimitadas veces hasta que todo parezca correcto.
Demo personalizada única
En lugar de migrar registros aleatorios, la opción de Demostración personalizada le permite seleccionar tickets específicos y probar su migración. Esto le ayuda a validar casos extremos antes de realizar la migración completa.
Lista de control de mapeo
Antes de iniciar la migración completa, revise los aspectos esenciales:
- Los tipos de campo coinciden (texto → texto, menú desplegable → menú desplegable, etc.).
- Todos los campos de destino obligatorios están asignados o tienen valores de respaldo.
- Los campos personalizados existen en el destino (o se crean a través del Asistente, cuando es compatible).
- Las opciones de selección única y múltiple se alinean, sin que queden valores sin asignar.
- Se verifica el soporte de campos personalizados de contacto y empresa (Entidad → Datos).
- Los campos multinivel están correctamente estructurados o ajustados.
- No hay campos duplicados ni condiciones de flujo de trabajo bloqueado en el destino.
- Se ha ejecutado y validado una demostración gratuita (y una demostración personalizada, si es necesario).
El mapeo de campos no es solo un paso técnico. Protege la lógica de automatización, la precisión de los informes y los flujos de trabajo diarios después de la migración. Una lista de verificación minuciosa hoy previene correcciones estructurales mañana.
FAQs sobre mapeo de campos predeterminados y personalizados
Help Desk Migration mapea campos vinculando tipos compatibles entre origen y destino. Se alinean por tipo (texto, desplegable, numérico, fecha, etc.) y los valores de los desplegables se mapean opción por opción. Puede validar todo con una Demo gratuita antes de la Full Migration.
Sí, en la mayoría de los casos deben existir en el destino para poder mapearse. No obstante, en muchas plataformas, los campos personalizados pueden crearse directamente en el Migration Wizard durante la configuración.
La herramienta admite campos de texto, numéricos, fecha, desplegables (selección única), multiselección, casillas de verificación, regex y fórmulas. Algunos tipos avanzados como regex o fórmulas pueden tener limitaciones según la plataforma.
Si no se alinean (por ejemplo, mapear erróneamente un desplegable a un campo de texto), los datos podrían no migrar correctamente o perder su estructura. Seguir la regla de "mapear por tipo" garantiza una transferencia segura.
Cada opción dentro de un desplegable, casilla o campo multiselección debe mapearse individualmente a su par exacto en el destino. Si un campo multiselección se mapea a uno de selección única, solo migrará el primer valor seleccionado.
"Unassigned" aparece cuando los valores del origen no coinciden con ninguna opción en el destino. Estos valores se resaltan antes de la Full Migration para que pueda corregirlos y evitar vacíos de datos.
El mapeo de campos personalizados de contactos y empresas solo es compatible con pares de plataformas específicos. Puede verificar la disponibilidad en Entidad → Datos. Si no es compatible, el equipo técnico ofrece opciones de gestión personalizada.
Si ambas plataformas admiten campos dependientes, deben tener estructuras idénticas. Si el destino no los admite, los datos pueden dividirse en campos desplegables separados o configurarse mediante un mapeo personalizado.
Los problemas más frecuentes son los nombres de campos duplicados en el destino y campos obligatorios sin valores. Se resuelven reutilizando campos existentes, mapeando todos los campos requeridos o aplicando valores por defecto.
Una Demo Migration valida su configuración con registros reales. Puede realizar Demos gratuitas ilimitadas o una Custom Demo para probar tickets específicos. Esto asegura que el mapeo funcione correctamente antes de transferir todos los datos.
