Tipos de dados em automações: por que texto, número e campo vazio quebram integrações

Uma tomada pode estar no lugar certo e ainda não servir ao aparelho que você quer ligar. Entre sistemas, o encaixe também depende do formato. Os tipos de dados determinam como valores podem ser interpretados, comparados e transformados dentro de uma automação.

Um campo que mostra “100” pode carregar texto ou número. Um telefone é formado por algarismos, mas não é uma quantidade para somar. Um valor vazio pode significar que ninguém respondeu, que a informação não se aplica ou que uma integração falhou. Tratar essas situações como equivalentes cria erros difíceis de perceber.

A aula de workflows automatizados da formação Club Martech conecta regras, transformações e tipos de dados às integrações da operação. O ponto prático é simples: antes de ligar dois sistemas, confira o que cada campo significa e qual formato o destino aceita.

Este guia usa exemplos hipotéticos de marketing e CRM para mostrar onde os erros aparecem. As convenções variam por ferramenta e interface. Nenhuma regra de conversão deve ser aplicada sem verificar o contrato específico da integração.

Tipos de dados e significado de negócio precisam combinar

O tipo descreve como um valor é representado. O significado explica o que ele mede ou identifica. Você pode ter dois campos numéricos compatíveis tecnicamente e ainda transmitir a informação errada: receita mensal no lugar de valor total de contrato, por exemplo.

Documente nome, significado, tipo, unidade e condição de ausência de cada campo importante. Acrescente um exemplo válido e um inválido. Essa ficha reduz a dependência de quem montou o fluxo e ajuda outra pessoa a interpretar uma falha.

Identificadores merecem atenção. Telefone, código postal e código de cliente podem exigir zeros à esquerda ou sinais que não fazem parte de uma quantidade numérica. Transformá-los em número por aparência pode remover informação necessária ao reconhecimento do registro.

Em um CRM, o campo de etapa pode ser exibido como um rótulo e transmitido como código interno. O destino precisa receber o valor aceito pela interface, não necessariamente o texto que aparece na tela. Nome semelhante não demonstra compatibilidade.

O erro comum é começar pela ação de envio e descobrir o formato depois. Inverta essa ordem: identifique o significado, consulte o formato aceito e só então desenhe a transformação.

Diferencie texto, número e valor lógico

Texto, ou string, serve para nomes, descrições e muitos identificadores. Número permite operações quantitativas dentro das regras do ambiente. Valor lógico representa condições como verdadeiro e falso.

A referência de tipos do JavaScript na MDN ajuda a entender essas distinções em uma linguagem usada por várias ferramentas. Isso não significa que todos os sistemas adotam suas regras de conversão. O formato recebido por uma API precisa ser conferido separadamente.

Uma condição de consentimento ou de elegibilidade não deve depender de uma comparação improvisada. Se a origem envia texto “sim” e o destino exige um booleano, documente a correspondência e o tratamento de qualquer outro valor. Um caso desconhecido precisa ter saída explícita.

Trate valores ausentes como estados diferentes

Campo ausente, texto vazio e null não são necessariamente equivalentes. Uma interface pode usar ausência para manter o valor atual e null para limpar o campo. Outra pode rejeitar null. A decisão correta depende da documentação e do comportamento verificado.

No formato JSON, null é um valor permitido; undefined não faz parte dos valores definidos pelo padrão. A RFC 8259 descreve a gramática e os tipos do formato. O padrão organiza representação, sem decidir o significado comercial de cada campo.

Considere um telefone que não veio no formulário. Se a automação atualiza um contato existente, enviar um valor vazio pode apagar o telefone que já estava no cadastro, dependendo da regra da interface. Antes de implementar, defina se a ausência deve preservar, limpar ou encaminhar o registro para revisão.

Faça o mesmo para resultados de enriquecimento. Não encontrar uma empresa não prova que ela não existe. Pode haver falha de consulta, dado insuficiente ou resposta sem correspondência. O estado técnico e a conclusão de negócio precisam continuar separados.

Adotar um valor padrão só para evitar erro pode esconder o problema. “Sem informação” é mais honesto que um setor ou porte preenchido sem evidência, desde que o destino e o processo saibam tratar esse estado.

Documente números, moeda, datas e fuso

Um valor monetário precisa de moeda, escala e regra de arredondamento. Algumas interfaces recebem unidades inteiras menores, como centavos; outras esperam um decimal. A transmissão de 100 pode representar valores diferentes se essa convenção não estiver definida.

Não substitua pontos e vírgulas indiscriminadamente. Um ponto pode separar milhares ou representar decimal conforme a origem. Receber texto de uma planilha e converter sem identificar a convenção pode gerar um número válido com magnitude errada, uma falha mais silenciosa que a rejeição do campo.

Datas exigem a mesma disciplina. Uma data de nascimento representa um dia de calendário; uma reunião representa um instante em determinado contexto de fuso. Transformar ambos pelo mesmo procedimento pode deslocar informações que não deveriam mudar.

Para atividades comerciais, registre o fuso adotado e teste mudanças de dia. Uma tarefa criada perto da meia-noite pode aparecer em outra data se origem e destino interpretarem o horário de maneiras diferentes. O teste precisa observar o que a pessoa verá na agenda, além do valor técnico enviado.

Esse cuidado afeta a leitura da jornada do cliente. Compra, ativação e renovação dependem de eventos e datas coerentes. Um intervalo negativo pode ser uma falha de registro, e não um comportamento inesperado do cliente.

Entenda listas, objetos e relações entre registros

Uma lista, ou array, contém elementos. Um objeto agrupa propriedades e valores. Uma empresa pode ter uma lista de contatos, e cada contato pode ser um objeto com nome e identificador. O fluxo precisa saber qual item está sendo processado e qual relação será preservada.

Se a ferramenta espera uma lista e recebe um único objeto, uma etapa pode falhar ou interpretar o conteúdo de outra maneira. Converter tudo para texto pode permitir o envio e destruir a estrutura que o próximo passo precisava usar.

A documentação de estrutura de dados do n8n descreve como os itens circulam entre nós. Use essa referência para entender o ambiente, mas confira também o contrato da ferramenta externa. O formato interno de um fluxo não é automaticamente o formato aceito pelo destino.

Um caso hipotético ajuda: uma compra tem três itens. Se o fluxo cria uma oportunidade por item quando o processo esperava uma por pedido, o CRM pode triplicar o volume comercial. Todos os campos podem estar tipados corretamente; o erro está na unidade de processamento.

Defina a unidade em cada trecho: pedido, item, contato ou empresa. Em seguida, confira quantas saídas cada entrada deve produzir. Essa verificação identifica duplicações que uma conferência apenas de valores individuais deixaria passar.

Valide antes de escrever no sistema de destino

Separe o fluxo em recepção, validação, transformação e escrita. A divisão facilita descobrir em que momento a informação mudou. Não é necessário criar dezenas de etapas; basta tornar observáveis as decisões que podem alterar o registro.

Monte casos com número em texto, data inválida, campo ausente, lista vazia, duplicata e valor fora do conjunto permitido. Use exemplos representativos da origem, com dados de teste. Um fluxo que passa apenas com o registro ideal ainda não foi avaliado para o trabalho real.

Quando a validação reprovar, informe o motivo e defina uma saída. Pode ser uma fila de correção, um alerta ou uma rejeição controlada. Continuar o processo com dados inventados para evitar uma interrupção costuma transferir a falha para uma etapa menos visível.

Considere a idempotência quando houver repetição. Se a integração recebe o mesmo pedido de novo, a regra deve esclarecer se atualiza, ignora ou cria outro registro. Identificador e estado de processamento ajudam a tomar essa decisão.

Registre erros sem copiar segredos ou dados pessoais desnecessários para os relatórios. Uma evidência útil identifica campo, regra e resultado, com os controles de acesso adequados. Observabilidade não exige expor todo o conteúdo recebido.

Além do valor isolado, confira a repetição do lote. Um teste com três pedidos deve permitir prever quantos contatos, oportunidades e atividades serão criados ou atualizados. Execute a mesma entrada novamente num ambiente controlado e compare o resultado com a regra documentada. Se o segundo envio duplicar negócios, o problema não está necessariamente no tipo de um campo, mas a validação do identificador e da unidade ajuda a localizá-lo. Depois simule um item inválido no meio do conjunto. Defina se o fluxo deve interromper tudo ou separar apenas aquele caso. As duas estratégias podem ser úteis em contextos diferentes, desde que o resultado parcial não seja apresentado como processamento integral.

Transforme a correção em contrato de dados

Depois de resolver uma falha, atualize a definição que governa a integração. O contrato de dados explica o que pode chegar, o que deve sair e como tratar incompatibilidades. Ele precisa ser conhecido por quem mantém origem e destino.

Guarde exemplos aprovados e reprovados para repetir a conferência após mudanças. Se um formulário passar a enviar uma lista em lugar de um texto, o conjunto de casos ajuda a detectar a quebra antes de afetar cadastros reais.

O assunto se conecta à transformação de dados para marketing. Extrair, transformar e carregar envolve preservar significado ao longo do caminho. Uma execução tecnicamente concluída não prova que o dado final continua representando o que a empresa pretendia medir.

Para começar, escolha uma integração que já dá retrabalho e documente cinco campos críticos. Confira tipo, unidade, ausência, identificador e exemplo. Teste casos difíceis antes de reativar a escrita. Esse pequeno contrato costuma mostrar se o problema está no encaixe técnico ou na definição do processo.