Foto: Alan Aprilio / Unsplash
Automações
Ligar dois sistemas sem mapear o que cada status de um significa no outro faz o fluxo travar ou gravar o valor errado quando aparece um status que ninguém previu
Pedro Toledo · 7 de novembro de 2026 · 3 min de leitura
Ligar dois sistemas sem mapear o que cada status de um significa no outro faz o fluxo travar ou gravar o valor errado quando aparece um status que ninguém previu — porque cada sistema usa nomes e etapas próprias ('Prospect' num, 'Novo' no outro), e sem uma tabela que diga o que equivale a quê, a integração ou falha ao receber um valor desconhecido ou o grava num campo que significa outra coisa. Por que os nomes parecerem óbvios, o que caracteriza um mapeamento de valores com dono e regra para o inesperado, e como montá-lo antes de ligar.
Achar que os nomes dos status dos dois sistemas querem dizer a mesma coisa costuma parecer razoável. Listar lado a lado os status de cada um, e ver quantos não têm correspondente exato, mostra o tamanho do trabalho que a integração ainda precisa fazer.
Ligar dois sistemas sem mapear o que cada status de um significa no outro faz o fluxo travar ou gravar o valor errado quando aparece um status que ninguém previu.
Por que os nomes parecem óbvios
"Aprovado", "Fechado" e "Concluído" parecem querer dizer a mesma coisa, mas cada sistema define suas etapas de forma própria. O que um chama de concluído pode corresponder a duas etapas no outro, ou a nenhuma, e a automação que copia o texto do status leva para o destino um valor que ali significa outra coisa.
O que caracteriza um mapeamento de valores com dono e regra para o inesperado
Um bom mapeamento é uma tabela que diz o que cada status de um sistema equivale no outro, quem é o dono de cada campo e o que fazer com um valor sem correspondência. Isso tem relação direta com integrar dois sistemas via API sem prever o que fazer quando a chamada falha ou expira — os dois casos apontam pro mesmo princípio de fundo: a integração precisa prever o que acontece quando algo foge do esperado, seja uma chamada que falha, seja um status que ninguém mapeou.
O que as fontes dizem
Um guia de integração entre CRM e ERP recomenda tabelas de mapeamento para listas de valores, com o exemplo de "Prospect" equivalendo a "New", e revisão depois de atualizações. A documentação do Oracle PeopleSoft CRM observa que sistemas externos usam status diferentes e define mapeamentos separados. As fontes também mandam decidir qual sistema é dono de cada dado e como resolver conflitos. Não encontrei fonte específica sobre valores sem correspondência.
Como montar o mapeamento antes de ligar
A forma prática é listar todos os status de cada sistema, escrever a equivalência de cada um, inclusive "sem equivalência", e decidir quem é dono de cada campo. Valores desconhecidos devem ir para uma fila de revisão com aviso ao responsável, os registros devem ter identificadores persistentes e cada sincronização deve ser registrada, com a tabela revisada quando um sistema mudar.
Um exemplo prático
Uma empresa liga o sistema de vendas ao de entregas. O status "Em separação" do primeiro não existe no segundo, e os pedidos com esse status param no meio do caminho sem aviso. Depois, ela escreve uma tabela com todos os status, define que "Em separação" equivale a "Novo" para a logística, cria uma fila para valores sem correspondência e avisa o responsável quando algo cai nela.
O ponto central
Antes de ligar dois sistemas, vale perguntar o que cada status de um quer dizer no outro. Dado que muda de sentido ao atravessar a integração é erro que se espalha sem aparecer.
