Dados padrão e personalizados são a base de um help desk. Eles definem como tickets se estruturam, fluxos rodam, relatórios surgem e como times medem o sucesso. Ao migrar a um novo sistema, o mapeamento de campos do help desk é tão vital quanto mover os dados em si.
Em suma, o Help Desk Migration torna o processo de mapear e migrar dados bem mais seguro e fácil — contanto que você siga as regras.
Neste guia prático, vamos guiar você pelos pontos fundamentais.
Campos Padrão vs. Personalizados no Help Desk Migration
Todo sistema de suporte técnico é estruturado em torno de campos. Alguns já vêm com o sistema; outros são criados por você.
Campos padrão
Por exemplo, no Zendesk, os campos padrão de um ticket incluem Solicitante, Responsável, Cópias (CCs), Assunto, Descrição, Status, Tipo, Prioridade e Etiquetas.
Esses elementos formam a base estrutural de cada ingresso.
Campos personalizados
Essas informações podem incluir o ID do pedido, o plano de assinatura, o tipo de produto, o nível de SLA, etc.
Elas capturam informações específicas do seu fluxo de trabalho e possibilitam automação e geração de relatórios personalizados.
Help Desk Migration migra ambos os tipos de campo.
Como esses campos são a estrutura básica dos seus dados, é fundamental que eles correspondam corretamente ao migrar para uma nova plataforma. E é aí que começam as preocupações dos nossos clientes.
Por que Mapear Dados é o Maior Medo em uma Migração de Dados
Quando os clientes utilizam Help Desk Migration, a maioria dos riscos help desk migration surge durante o mapeamento de campo.
Os usuários podem experimentar:
- Perda de granularidade do campo (por exemplo, um campo de seleção múltipla passa a ser um campo de seleção única e mantém apenas um valor)
- Status de tickets alterados ou distorcidos
- Bilhetes perdidos
- Usuários ou organizações duplicados
- Gatilhos de automação indesejados
A boa notícia? Todos esses riscos, sejam eles gatilhos indesejados ou perda de dados durante a migração, podem ser controlados com a configuração correta e o preparo prévio à migração, o que exige compreender o que a ferramenta de migração pode e não pode fazer.
Vamos começar pelo básico. Quais objetos o Help Desk Migration migra?
Quais Objetos se Mapeiam no Help Desk Migration?
Help Desk Migration permite a transferência de campos padrão e personalizados em tickets, problemas, alterações, contatos, empresas, artigos e tarefas de gerenciamento de projetos entre plataformas.
Tipos de campos suportados na Help Desk Migration
A ferramenta migra todos os principais tipos de campos:
- Campos com opções predefinidas, incluindo listas suspensas, caixas de seleção e seleção múltipla
(por exemplo, Tipo de Problema, Região, Nível de SLA) . No Migration Wizard, eles são exibidos como campos de lista suspensa. - Texto / cadeia de caracteres . Campos de entrada de texto livre para textos curtos ou longos.
- Numérico. Campos que armazenam números, como IDs, quantidades ou referências internas.
- Data. Campos que armazenam datas do calendário (por exemplo, data de renovação, início do contrato, prazo personalizado).
- Campos de expressão regular. Campos validados por uma regra baseada em padrões. Por exemplo, um campo que aceita apenas um ID de pedido formatado corretamente, como ORD-12345. Esses campos são exibidos para mapeamento entre plataformas, mas seus dados são migrados apenas para Zendesk e Pylon , onde a lógica de padrões é totalmente compatível.
- Campos de fórmula. Campos cujos valores são calculados automaticamente com base em outros campos. Por exemplo, um campo que calcula o Custo Total a partir da Quantidade × Preço, ou uma pontuação de prioridade derivada de múltiplas entradas. Em algumas plataformas, os campos de fórmula estão disponíveis para mapeamento como um tipo de campo. A migração do valor calculado depende de como a plataforma armazena esses dados.
O primeiro passo para mapear corretamente esses tipos de campos de help desk começa com uma regra importante.
Regra: Mapear Campos Padrão e Custom por Tipo
Uma migração precisa começa com a consistência dos tipos de campo. Ao mapear campos, sejam eles padrão ou personalizados, certifique-se de que os tipos de campo correspondam entre os sistemas de origem e destino .
- Um campo de texto só pode ser mapeado para outro campo de texto.
- Um campo numérico deve ser mapeado para um campo numérico.
- Um campo suspenso deve estar conectado a outro campo suspenso com valores correspondentes.
- Um campo numérico ou um campo de data também pode ser mapeado para um campo de texto no sistema de destino.
- E assim por diante.
Se os tipos não forem compatíveis, os dados podem não ser migrados corretamente ou perder sua estrutura.
Campos de Seleção: Dropdown, Seleção Múltipla e Checkbox
Mapear dropdowns no Help Desk Migration requer alinhar valores de cada opção, não só o nome do campo. Esta regra vale para todo campo de seleção.
Ou seja, não basta ligar "Tipo de Ticket" a "Categoria". Cada opção dentro do campo deve ser mapeada ao seu par exato (por exemplo, de "Incidente" para "Incidente" ou de "Problema" para "Problema").
Além disso, cuide ao migrar campos de Seleção (uma só opção) e de Seleção Múltipla (várias opções) no Assistente de Migração. Campos de Seleção > Seleção e Seleção > Seleção Múltipla migram como esperado, mas ao mapear de Seleção Múltipla > Seleção, apenas o primeiro valor escolhido migra.
Lidando com Opções de Seleção Não Mapeadas em Checkbox, Seleção Múltipla e Dropdown
Às vezes, valores de campos não migram porque não batem exatamente entre a origem e o destino.
Se necessário, nossa equipe ajustará as configurações para garantir que cada valor seja inserido no local correto.
Campos que não migram
Os campos suspensos sem opções não aparecerão na interface de mapeamento, e esse é outro problema comum com campos suspensos.
Além disso, os valores excluídos das listas suspensas não são exibidos na interface de mapeamento. Por exemplo, um ticket pode ainda conter um valor histórico da lista suspensa, mas se esse valor tiver sido removido da lista de opções atual, ele não aparecerá durante o mapeamento. Nesses casos, o sistema mapeia automaticamente esses registros para o valor padrão da lista suspensa no destino.
Como não há valores para alinhar, o sistema os exclui automaticamente da interface de mapeamento.
Criando Campos Personalizados Antes da Migração
Campos personalizados devem existir no sistema de destino antes de serem mapeados.
Se um campo não existe no destino, não há nada para conectá-lo, e os dados não serão movidos direito. Por isso, preparar campos personalizados cedo no processo é um passo vital em qualquer migração.
Mas há algumas exceções.
Lógica de Criação de Campos Específicos por Plataforma
Em geral, os clientes precisam criar campos antes da migração, direto no help desk de destino.
Certifique-se de seguir estas regras de mapeamento de campos:
Freshdesk
Os campos de seleção são criados como menus suspensos personalizados.
Zendesk
O sistema verifica se o campo deve ser um marcador (seleção única) ou de seleção múltipla e cria um de acordo.
Intercom
Os campos de seleção são criados com o tipo de lista.
Jira Service Management
O sistema determina se o campo deve ser do tipo seleção simples ou múltipla, com base na estrutura da fonte.
Além disso, se uma lista suspensa contiver centenas ou milhares de opções, criá-la por meio do assistente pode retornar um erro. Em alguns casos, o campo é criado, mas não é adicionado automaticamente ao projeto, exigindo que um engenheiro o verifique e ajuste.
Intercom
A API limita os campos suspensos a 250 valores, mas a interface suporta campos com mais valores.
Limitações vitais para plataformas
O cliente não pode criar campos duplicados através do assistente, e os campos suspensos mantêm as mesmas opções do sistema de origem.
Limites no Mapeamento de Campos de Contato e Empresa
O Help Desk Migration aceita a migração de campos personalizados para contatos e empresas em pares de migração selecionados.
Para checar se a migração de campos de empresa e contato é aceita no seu caso, navegue em Entidade → Dados.
Se você vir “Describe - 1” ao lado dos campos personalizados de contato ou empresa, significa que eles podem ser migrados dentro do fluxo automático padrão.
Caso contrário, esses campos não migrarão sozinhos, mesmo que campos idênticos já existam na plataforma de destino. Em tais casos, nosso time técnico faz um ajuste manual.
Do lado do cliente, se a migração de campos personalizados de contato e empresa não for aceita para o seu par específico, eles só verão os campos padrão disponíveis para mapeamento (como Nome, E-mail, etc.).
Migração de Campo Dependente Multinível
Um campo multinível (também chamado de campo aninhado ou dependente) contém várias camadas de opções. A escolha feita no primeiro nível determina quais opções estarão disponíveis no próximo.
Um exemplo simples é o campo Endereço:
Nível 1 → País
Nível 2 → Cidade (filtrado por país)
Nível 3 → Rua (filtrado por cidade)
Cada seleção reduz o conjunto seguinte de opções.
Por que Campos Multinível Causam Erros
Campos multinível geram desafios se a estrutura não for replicada corretamente no sistema de destino final.
Como o Help Desk Migration Trata Campos Multinível Sem Suporte no Destino
Se a origem tem um campo multinível mas o destino não aceita campos dependentes, há soluções práticas.
Opção 1: Dividir um Campo Multinível em Campos de Dropdown Separados
Se a origem tem um campo multinível mas o destino não, o cliente pode criar campos de dropdown distintos no destino — um para cada nível.
Por exemplo:
- País (dropdown)
- Cidade (dropdown)
- Rua (dropdown)
Nessa configuração, as opções do mesmo campo de origem são mapeadas para vários campos de destino, alinhados de acordo com seus respectivos níveis.
Opção 2: Mapear Vários Campos em um Único Campo Multinível
Se o sistema de origem tiver campos suspensos separados (por exemplo, País, Cidade, Rua), mas o sistema de destino suportar um único campo multinível, o mapeamento personalizado é possível.
Nesse caso, nossa equipe pode configurar o mapeamento.
O cliente deve fornecer um arquivo de mapeamento estruturado que oriente sobre como os níveis devem ser combinados.
Campos multiníveis exigem atenção redobrada, pois armazenam não apenas valores, mas também relações estruturadas entre eles. Uma preparação adequada garante que essa estrutura não se perca durante a migração.
Regras de Pular, Campos Obrigatórios e Migração de Valor Padrão
Mapear campos não é só ligá-los. É também controlar quais dados aparecem no sistema de destino — com constância e em escala.
Pular este campo
Disponível apenas para campos não obrigatórios.
Essa opção deixa o campo de destino vazio em todos os tickets migrados, independentemente do valor de origem.
Use a opção "Ignorar este campo" nas migrações quando:
- O campo existe no destino, mas não é mais relevante.
- Este campo é opcional e pode ser deixado em branco sem problemas.
Valor Padrão
Esta opção define um valor fixo para um campo suspenso em todos os tickets migrados.
Por exemplo, se você definir Tipo → Problema, todos os tickets migrados terão “Problema” selecionado no campo Tipo, independentemente do valor original.
A opção de valor de campo padrão é útil quando:
- Padronização de dados históricos.
- Transição para uma estrutura de campo simplificada.
- Aplicando um novo modelo de categorização.
Utilizar para valores padrão ou vazios
Disponível apenas ao mapear campos obrigatórios.
Essa opção preenche, por padrão, um campo de destino obrigatório somente se o campo de origem mapeado estiver vazio em um determinado ticket.
Isso significa:
- Se o valor de origem existir → a migração ocorre normalmente.
- Se o valor de origem estiver vazio → o valor alternativo selecionado será aplicado.
Isso evita erros de migração, preservando os dados reais onde eles existirem.
Sem preencher
Disponível para mapeamento de campo opcional.
Se determinados valores mapeados forem selecionados na origem, esta opção deixará o campo de destino vazio.
É útil quando:
- Alguns valores de origem já não são relevantes.
- Você deseja excluir intencionalmente categorias específicas da migração.
- Este campo é opcional e deve permanecer em branco sob certas condições.
Esses controles oferecem a flexibilidade necessária para refinar e padronizar os dados durante a migração.
Erros Comuns de Mapeamento e Como Resolvê-los
Para manter o rigor da sua solicitação, traduzi o texto preservando exatamente os 163 caracteres (incluindo espaços) do original em inglês.
Nome duplicado
O erro de campo duplicado ocorre quando o sistema de destino já contém um campo com o mesmo nome.
Mesmo que você não veja imediatamente, o campo pode:
- Existir, mas estar inativo
- Pertencer a um projeto diferente (em sistemas baseados em projetos)
- Ficar oculto pelas configurações
Como resolver:
- Verifique se o campo já existe no destino.
- Ative ou reutilize o campo existente em vez de criar um novo.
- Em plataformas baseadas em projetos, certifique-se de que o campo foi adicionado ao projeto correto.
Obrigatório = Campo ausente
Esse erro ocorre quando um campo obrigatório no sistema de destino não recebe nenhum valor durante a migração.
Pode ser necessário preencher um campo:
- Para criação de ingressos
- Para encerramento de bilhetes
- Devido a regras ou condições específicas
Por exemplo, um sistema pode impedir o fechamento de um chamado se um campo obrigatório (por exemplo, Tipo de Resolução) estiver vazio. Esses requisitos podem ser configurados diretamente nas configurações do campo ou controlados por condições de fluxo de trabalho.
Às vezes, um campo não parece obrigatório no mapeamento pois regras condicionais só valem em certos casos. Mas, na migração, tais regras podem barrar updates de tickets se o campo estiver vazio.
Como corrigir o erro de campo obrigatório:
- Certifique-se de que todos os campos obrigatórios estejam mapeados.
- Use “Valor padrão” ou “Usar para valores padrão ou vazios” para evitar campos obrigatórios vazios.
- Analise as condições de campo e as regras de fluxo de trabalho antes de iniciar a Migração Completa.
Conhecer esses dois tipos de erros ajuda a evitar interrupções e mantém a migração tranquila do início ao fim.
Demo como Validação (Não Teoria)
A Migração Demo mostra como suas regras de mapeamento agem antes da Migração Total ocorrer.
Demo Grátis Ilimitada
A migra 20 tickets aleatórios com todos os registros ligados, além de 20 artigos da base de conhecimento. Ela gera um relatório detalhando quais registros migraram com sucesso e quais falharam no processo.
Você pode rodar a Demo quantas vezes quiser até que tudo pareça correto.
Demo Personalizada Única
Em vez de migrar registros aleatórios, a opção de Demo Personalizada permite selecionar tickets específicos e testar como eles migram. Isso ajuda você a validar casos isolados antes de fazer a Migração Total.
Checklist de Mapeamento
Antes de iniciar a Migração Total, revise os pontos essenciais:
- Os tipos de campo correspondem (texto → texto, lista suspensa → lista suspensa, etc.).
- Todos os campos de destino obrigatórios estão mapeados ou possuem valores alternativos.
- Existem campos personalizados no destino (ou são criados por meio do assistente, quando compatível).
- As opções de seleção única e múltipla estão alinhadas, sem valores não atribuídos restantes.
- O suporte para campos personalizados de contato e empresa foi verificado (Entidade → Dados).
- Os campos multiníveis estão devidamente estruturados ou ajustados.
- Não há campos duplicados nem condições de bloqueio no fluxo de trabalho de destino.
- Uma demonstração gratuita (e uma demonstração personalizada, se necessário) foi executada e validada.
Mapear campos não é só técnico. Protege a automação, relatórios e fluxos diários pós-migração. Um checklist atento hoje evita ajustes estruturais amanhã.
Perguntas Frequentes sobre Mapeamento de Campos Padrão e Personalizados
O Help Desk Migration mapeia campos combinando tipos de campos compatíveis entre os sistemas de origem e destino. Campos padrão e personalizados são alinhados com base no tipo (texto, lista, numérico, data, etc.), e valores de lista suspensa são mapeados opção por opção. Você pode validar tudo com uma Demo Grátis antes de rodar a Migração Total.
Sim, na maioria dos casos os campos personalizados devem existir no sistema de destino antes de serem mapeados. No entanto, para muitas plataformas, campos personalizados podem ser criados diretamente no Assistente de Migração durante a configuração.
A ferramenta aceita campos de texto, numéricos, data, lista (seleção única), seleção múltipla, caixa de seleção, regex e campos de fórmula. Alguns tipos avançados, como regex e campos de fórmula, podem ter limitações específicas da plataforma.
Se os tipos de campos não se alinharem (por exemplo, mapear uma lista suspensa para um campo de texto incorretamente), os dados podem falhar na migração ou perder a estrutura. Seguir a regra de “mapear por tipo” garante uma transferência de dados segura e precisa.
Cada opção dentro de um campo de lista, caixa de seleção ou seleção múltipla deve ser mapeada individualmente para sua contraparte exata no sistema de destino. Se um campo de seleção múltipla for mapeado para um de seleção única, só o primeiro valor migrará.
“Não atribuído” aparece quando valores de lista na origem não coincidem com nenhuma opção no destino. Esses valores são destacados antes da Migração Total para que você possa corrigi-los com antecedência e evitar lacunas nos dados.
A migração de campos personalizados de contato e empresa é aceita apenas para pares de plataformas específicos. Você pode checar em Entidade → Dados. Se não houver suporte, o time técnico pode fornecer opções de tratamento personalizado.
Se ambas as plataformas aceitarem campos dependentes, elas devem ter estruturas idênticas. Se o sistema de destino não aceitar campos multinível, os dados podem ser divididos em campos de lista separados ou configurados via mapeamento customizado.
Os problemas comuns são nomes de campos duplicados no destino e campos obrigatórios sem valores. Isso pode ser resolvido reutilizando campos existentes, mapeando todos os campos obrigatórios ou aplicando valores padrão de reserva.
Uma Migração Demo valida sua configuração de mapeamento usando registros reais. Você pode rodar Demos Grátis ilimitadas ou usar uma Demo Personalizada para testar tickets específicos. Isso garante que seu mapeamento funcione antes de mover tudo.
