>_
Modo Build
guiaJornada Builder

Como estruturar dados em projetos low-code (antes de automatizar qualquer coisa)

A automação quebra quando os dados são bagunçados. Aprenda a estruturar planilhas, bases no Notion e tabelas no Supabase para que suas automações funcionem de verdade.

22 de junho de 20268 min de leitura

A maioria das automações que "não funcionam" não é problema da ferramenta de automação. É problema dos dados.

Planilha com colunas misturadas, campos que às vezes têm valor e às vezes não, datas em formatos diferentes na mesma coluna, texto onde deveria ser número — qualquer um desses problemas quebra um fluxo que dependeria de ser simples.

Antes de criar qualquer automação, você precisa ter clareza sobre como os dados estão estruturados.

O princípio base: cada campo faz uma coisa

O erro mais comum em bases de dados improvisadas é misturar informações num campo só.

Errado:

nome_contato: "João Silva - CEO - joao@empresa.com - (11) 99999-9999"

Certo:

nome: "João Silva"
cargo: "CEO"
email: "joao@empresa.com"
telefone: "+55 11 99999-9999"

Quando as informações estão separadas, você consegue filtrar, buscar, ordenar e enviar para qualquer sistema sem precisar de parsing manual. Quando estão juntas, cada automação precisa descobrir onde começa e termina cada parte — e isso sempre quebra em alguma edge case.

Regra: um campo, uma informação. Sem exceção.

Tipos de dados e por que importam

Cada campo deve ter um tipo definido e manter esse tipo em todos os registros.

| Tipo | Exemplos | Problema se não definido | |------|----------|--------------------------| | Texto | nome, descrição, status | Sem problema, mas evite colocar números aqui | | Número | preço, quantidade, ID | "R$ 150,00" não é número — remove o símbolo antes | | Data | criado_em, prazo | "15/06" sem ano quebra em virada de ano | | Boolean | ativo, enviado, aprovado | Use true/false, não "sim"/"não"/"x" | | Relação | cliente_id, produto_id | ID numérico, não nome (nomes mudam) |

Datas merecem atenção especial: use sempre o formato ISO 8601 (YYYY-MM-DD ou YYYY-MM-DDTHH:mm:ssZ). É o formato padrão que todas as ferramentas de automação entendem sem conversão.

Ferramentas e quando usar cada uma

Google Sheets / Excel

Ponto de partida para quem está começando. Fácil, acessível, integra com N8N e Make nativamente. Limitação: sem tipos de dados forçados, sem relações entre tabelas, performance ruim com muitos dados.

Use para: prototipagem de automação, dados de volume baixo (< 5.000 linhas), equipes pequenas.

Notion Database

Melhor estrutura do que planilhas, com tipos de campo, relações e visualizações. Integra com N8N, Make e diretamente via API.

Use para: gestão de conteúdo, CRM simples, base de conhecimento com automação. Não use para volumes altos ou dados relacionais complexos.

Airtable

A melhor relação entre facilidade de uso e poder. Tipos de campo forçados, relações entre tabelas, views configuráveis. A API é muito boa para automação.

Use para: projetos que vão escalar um pouco, bases com relações entre entidades, quando você precisa de mais controle do que o Notion oferece.

Supabase

PostgreSQL gerenciado com API REST automática. O salto de complexidade é maior, mas o poder também. Tipos forçados, relações reais, consultas SQL, row-level security.

Use para: produtos com usuários, dados que crescem muito, quando você precisa de lógica de banco de dados real.

A estrutura mínima que todo projeto precisa

Independente da ferramenta, todo projeto precisa de:

Campo de ID único — cada registro tem um identificador que nunca muda. Não use nome como ID. Use número sequencial ou UUID.

Timestampscriado_em e atualizado_em em todo registro. Você vai precisar disso mais cedo do que pensa para debugar problemas de sincronização.

Status definido — se o registro passa por estados (pendente → processando → concluído), defina esses estados como uma lista de valores fixos. Nunca texto livre.

Campos separados para cada informação — seguindo o princípio da aula.

Normalização básica: quando separar em tabelas

Se você tem uma base de clientes e cada cliente tem múltiplos pedidos, não coloque os pedidos como colunas do cliente.

Errado:

cliente: nome, pedido_1, data_pedido_1, pedido_2, data_pedido_2 ...

Certo:

tabela clientes: id, nome, email
tabela pedidos: id, cliente_id, produto, data, valor

A relação é feita pelo cliente_id. Isso permite que cada cliente tenha qualquer número de pedidos sem quebrar a estrutura.

Ferramentas como Airtable e Supabase suportam isso nativamente. No Google Sheets você precisa simular com fórmulas ou aceitar a limitação.

Antes de criar a automação: o checklist

Antes de ligar o primeiro fluxo no N8N ou Make, confirme:

  • [ ] Todos os campos têm nomes claros (sem abreviações ambíguas)
  • [ ] Tipos de dados são consistentes em todos os registros
  • [ ] Datas estão em formato ISO
  • [ ] Não há campos com múltiplas informações misturadas
  • [ ] Há um ID único por registro
  • [ ] Há criado_em e atualizado_em
  • [ ] Status e categorias são lista de valores fixos (não texto livre)
  • [ ] Você testou ler os dados via API antes de construir a automação

Esse checklist parece chato. Mas é o que a diferença entre uma automação que funciona na primeira semana e uma que quebra silenciosamente em dois meses.

#dados#low-code#supabase#notion#airtable#automação#estrutura