A Resposta Breve
O Data Mapping não é uma simples planilha de tradução de campos, mas sim o documento que estabelece o significado de cada dado que a organização levará para o Salesforce. Quase todos os erros de carregamento que parecem técnicos – formato de data, Picklist não reconhecido, relacionamento quebrado – nascem de uma decisão de negócio não tomada.
A ordem que funciona: primeiro, definem-se quais entidades serão migradas; em seguida, quem é o proprietário de negócio de cada entidade; depois, quais campos têm um consumidor real; e só depois, escrevem-se as regras de conversão. Quando se começa na direção oposta, a equipe técnica toma decisões de negócio silenciosamente – e isso é descoberto três meses após o Go Live, quando um relatório de receita não fecha.
Mais informações sobre o planejamento completo da conversão estão disponíveis em Migração de Dados para Salesforce.
Os Três Tipos de Lacunas Reveladas pelo Mapping
| Tipo de Lacuna | Exemplo Comum | Quem Decide |
|---|---|---|
| Lacuna Semântica | "Cliente ativo" = fez uma compra este ano em um sistema, = não foi bloqueado em outro sistema | Proprietário do processo de negócio |
| Lacuna Estrutural | Um cliente com cinco endereços versus o modelo Account/Contact | Arquiteto de Dados |
| Lacuna de Qualidade | 18% dos registros sem ID de empresa válido | Data Owner + Regulação |
A lacuna semântica é a mais dispendiosa, pois não causa erro no carregamento. O dado é inserido com sucesso, a automação é executada sobre ele, e o relatório exibe um número incorreto que parece plausível. Lacunas estruturais resultam em erros de carregamento e, portanto, são detectadas precocemente. Lacunas de qualidade são detectadas se – e somente se – limites de aceitação forem definidos antecipadamente.
A Camada de Significado: Data Dictionary Antes da Planilha de Mapping
Antes de mapear campo a campo, escreve-se uma definição do glossário para cada entidade central: o que é uma Account, o que distingue um Lead de um Contact nesta organização, quando uma Opportunity é fechada. Essas definições são curtas – duas linhas por entidade – mas são o que permite resolver disputas em vez de apenas apontá-las.
O teste simples: peça a três pessoas de três departamentos que definam "cliente" separadamente. Se as definições forem diferentes, a migração transferirá três verdades distintas para a mesma tabela.
Anatomia de uma Linha de Mapping Correta
Cada linha na planilha deve responder a sete perguntas: de qual objeto e campo na origem, para qual objeto e campo no Salesforce, qual o tipo e comprimento do dado, qual a regra de conversão, o que acontece com um valor vazio, qual o valor padrão, e quem aprovou. Uma linha que faltar uma dessas colunas voltará como uma pergunta no meio de um carregamento noturno durante o Cutover.
Três regras de trabalho que evitam problemas:
- Sem conversão silenciosa. Qualquer valor que o sistema "corrige" automaticamente deve ser registrado em um log de exceções.
- O valor padrão é uma decisão de negócio. Quem define
Country = ILcomo padrão deve ser o responsável pelos relatórios por região. - IDs Externos antes de tudo. Para cada entidade, guarda-se um External ID do sistema de origem. Sem ele, não há Reconciliation e não há segunda execução.
Transformações: Onde Erros Acontecem
As conversões que causam mais danos são, ironicamente, as mais simples. Datas sem fuso horário movem registros em um dia; nomes que passam por Trim e Upper sem uma regra uniforme criam novas duplicidades logo após termos limpado as antigas; valores monetários convertidos para uma moeda única com taxa diária geram discrepâncias nos relatórios em comparação com o ERP.
A regra: toda conversão numérica ou monetária é verificada comparando somas, não comparando registros. Uma contagem idêntica não é evidência de correção.
Quem ainda não resolveu a questão da Fonte da Verdade encontrará informações em Fonte da Verdade na Organização, e sobre a janela de transferência em Cutover e Reconciliation.
Cenário: Empresa de Serviços com Dois Sistemas de Origem
Uma organização de serviços com 90 mil clientes abordou uma conversão a partir de dois sistemas: um sistema de cobrança legado e um sistema de serviço adquirido com uma subsidiária. A primeira planilha de Mapping foi marcada como "pronta" em duas semanas – 340 campos mapeados.
Na primeira execução do Rehearsal, 97% dos registros foram carregados. O problema foi descoberto no Reconciliation: o total dos saldos no Salesforce era 4,1% menor que no ERP. A razão não foi um carregamento mal sucedido, mas sim que todos os registros com saldo negativo (créditos) foram mapeados para um campo com uma Validation Rule que impede valores negativos – e foram silenciosamente definidos como zero.
A correção foi em dois níveis: uma regra de conversão explícita para créditos, e também uma mudança de política – toda regra que zera ou encurta um valor deve gerar uma linha de exceção. Na segunda execução, o número de exceções subiu para 1.900, e isso foi um progresso: as exceções estavam visíveis em vez de ocultas. A terceira execução baixou para 40 exceções documentadas, e só então foi definida a data do Cutover.
Riscos Comuns e Ações Preventivas
| Risco | Como se manifesta na prática | Ação Preventiva |
|---|---|---|
| Transferir todo o histórico | Volume, duplicidades e informações sem valor migram para o novo sistema | Definir políticas de Retention e limites de qualidade |
| Mapping apenas técnico | Campos são transferidos sem entender o significado de negócio | Data Dictionary e proprietários de negócios |
| Conversões silenciosas | Valores são corrigidos automaticamente e ninguém sabe | Log de exceções obrigatório para cada regra de conversão |
| Sem Rehearsal | A janela de inatividade se estende e surgem surpresas | Pelo menos duas execuções completas |
| Sem External ID | Impossibilidade de verificar, corrigir ou reexecutar | Manter a chave de origem para cada entidade |
Como Medir o Sucesso
| Área | O que Medir | Frequência de Verificação |
|---|---|---|
| Completeness | Taxa de campos obrigatórios preenchidos no destino | Antes e depois de cada carregamento |
| Reconciliation | Correspondência de contagens, somas e relacionamentos com a origem | Em cada Rehearsal e no Cutover |
| Exceções | Número de linhas de exceção abertas por gravidade | Diariamente durante o período de conversão |
| Campos sem consumidor | Quantos campos migrados não foram lidos em 90 dias | Uma vez após o Go Live |
O último indicador é uma preparação para o próximo ciclo: ele mostra quanto do trabalho foi desnecessário e direciona o escopo da próxima conversão.
Organizações que preferem acompanhamento profissional na construção do Mapping o fazem no âmbito do serviço de Integrações e Dados.
Checklist Antes do Primeiro Carregamento
- ☐ Um Data Dictionary conciso para cada entidade central, aprovado pelo negócio
- ☐ Lista de campos com consumidor definido; o restante para arquivo
- ☐ External ID para cada entidade que será transferida
- ☐ Tabela de Value Mapping completa, incluindo valores para valores não reconhecidos
- ☐ Regra explícita para cada valor vazio e para cada valor padrão
- ☐ Cada regra de conversão gera uma linha de exceção em vez de uma correção silenciosa
- ☐ Cenário de Reconciliation: contagem, soma, relacionamento, amostragem manual
- ☐ Limite de exceções acordado acima do qual não se realiza o Cutover
- ☐ Versão e assinatura na planilha de Mapping
- ☐ Plano de Rollback e reexecução
Recursos Profissionais
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data