Mantendo os dados consistentes

🌐 Também em 28 idiomas

English · Español · 日本語 · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Imagem gerada com IA

Traduzido por IA. Ainda não revisado pela comunidade. Ler em inglês

Módulo 9 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Propriedade e ciclo de vida · Próximo: Projete o modelo físico Salesforce

A pergunta que este módulo responde: Como mantenho os dados consistentes, e quanto custa cada camada?

Todo mundo quer dados limpos. Nunca entrei numa reunião de requisitos em que alguém dissesse: “O que gostaríamos mesmo é de dados inconsistentes.” A discordância vem depois: onde aplicamos as regras? Na tela? Um campo obrigatório? Uma lista de opções, uma regra de validação, uma regra de duplicidade, um flow, Apex? Todos ajudam. Não são intercambiáveis, e cada camada tem um custo.

Minha regra geral é empurrar a regra o mais para baixo que for razoável. Se um valor só pode ser uma de cinco coisas, não deixe as pessoas digitarem qualquer coisa para limpar depois com automação. Se dois registros nunca podem compartilhar um identificador, não conte com alguém percebendo isso num relatório. Se uma regra precisa valer quer o registro venha de uma tela, de uma API, de uma integração, de uma carga de dados ou de um agente, não a aplique só na interface. Quanto mais perto dos dados a regra fica, mais difícil é contorná-la. Chamo isso de a escada da consistência.

Degrau um: o tipo de campo e o vocabulário

A primeira regra de consistência é a do módulo 6: escolha o tipo certo. Uma data é Data, um momento é Data/Hora, dinheiro é Moeda. Isso é consistência antes de alguém escrever uma regra.

Faça do status de uma entrega um campo de texto e você vai ganhar Delivered, delivered, DELIVERED, Complete, Done e Dropped off, e alguém vai ter de descobrir se esses seis significam a mesma coisa. Ou defina o vocabulário uma vez: Delivered (Entregue), um valor, um significado. Torne-o uma lista de opções restrita, para que rejeite qualquer coisa fora da lista, até pela API, e um conjunto de valores global quando vários campos compartilham a lista (o módulo 6 tem os detalhes).

Mas não use uma lista de opções só para impedir as pessoas de digitar. É mesmo um valor, ou outra entidade? Nove centros de distribuição com um nome cada podem parecer uma lista de opções; nove com endereços, gerentes, capacidade e caminhões são registros. A regra deve reforçar o modelo, não compensar um modelo ruim. E se for realmente um vocabulário controlado, controle-o no campo. Não permita o caos para depois construir um flow que transforme AZ, Arizona, Ariz e região de Phoenix no valor que você queria desde o início.

Degrau dois: obrigatório e único

Obrigatório e Único são atraentes porque são simples: marque a caixa, problema resolvido. Às vezes. Se todo caminhão tem um número de frota desde o dia em que é criado, e nenhum par de caminhões compartilha um, as duas caixas expressam regras de negócio reais. Isso é consistência forte.

Mas, depois que a plataforma aplica uma regra, ela não se importa que seu processo tenha uma exceção na terça à tarde. Uso este exemplo em aula há anos. Um objeto existe há algum tempo, com muitos registros. Alguém acrescenta um campo e marca Obrigatório. Testa criar um registro: funciona lindamente. Aí, sábado à noite, deploy, os testes rodam, e uma classe de teste antiga cria o objeto sem o campo novo. Bum. Ou alguém edita um registro antigo de antes de o campo existir. Ou a integração envia o mesmo payload que envia há cinco anos. Bum. “Mas não mexemos naquele campo.” A plataforma não se importa: você mudou o contrato do que é um registro válido. Uma regra nova não afeta só os dados novos; ela muda o que você pode fazer com os dados antigos.

Degrau três: regras de validação

As regras de validação nos deixam dizer coisas muito mais ricas. Se o status é Entregue, o horário real da entrega precisa estar preenchido. Se a parada é uma instalação, o checklist precisa estar completo antes de a parada poder ser fechada. Elas rodam quando o registro é salvo, então protegem o registro quer ele tenha sido salvo de uma página, da API, de uma carga de dados, de uma integração ou de um agente. Esse é o ponto. Se a regra precisa proteger o registro, coloque-a onde toda gravação a encontra.

Elas também têm dentes. Essa é a força e o custo delas.

O problema dos registros antigos

É aqui que fica feio. Você tem um milhão de registros, e hoje acrescenta uma regra: o horário da entrega não pode ser anterior à saída da rota. Sensato. Mas vinte mil registros antigos a violam, graças a uma migração de sete anos atrás. Um usuário abre um deles e muda o telefone. Salvar. A regra dispara. “Mudei um número de telefone. Por que você está me falando de um horário de entrega de 2019?” Pergunta justa.

Então uma regra de validação não deve dizer só o que precisa ser verdade. Deve dizer quando aplicar isso. Funções como ISNEW() e ISCHANGED() deixam você limitar uma regra a registros novos, ou a gravações em que os campos relevantes realmente mudam (Validation Rule Considerations (opens in a new tab), em inglês).

Mas um registro não muda só quando uma pessoa o edita, e muitos dos motivos estão fora do seu controle. A integração atualiza o status durante a noite. Um flow carimba uma data. Um gerente reatribui um território e o proprietário muda em dez mil registros. Alguém edita um item de entrega, o resumo de totalização na entrega é recalculado, e isso salva a entrega, então a regra de validação da entrega dispara para um usuário que nunca tocou nela (a página Roll-Up Summary Field (opens in a new tab), em inglês, avisa que os erros de validação podem aparecer no detalhe ou no mestre). Cada uma dessas gravações encontra a sua regra nova. Então, para cada regra nova, pergunte: essa regra deve valer para aquela gravação?

Estas são as escolhas, e você as tece dentro da regra:

• Sempre, em toda gravação. Certo quando a regra é de fato sobre o registro e os dados antigos passam. Mas saiba o que “toda gravação” significa: um job em lote que só muda o proprietário, ou qualquer pequena edição em qualquer campo do registro, também precisa passar por ela.
• Só para registros novos, com ISNEW(). A regra verifica o registro uma vez, quando ele é criado, e nunca mais. O passado fica como estava, mas o futuro também: uma edição posterior pode fazer um registro novo violar a regra, e ninguém vai impedir. Se isso importa, combine com a próxima.
• Só quando os campos de que ela trata mudam, com ISCHANGED(). Editar o número de telefone não acorda a regra do horário da entrega.
• Não para certos autores da gravação. Uma permissão personalizada, verificada na fórmula como $Permission, deixa passar o usuário de integração ou uma migração de dados, enquanto as pessoas continuam sujeitas à regra (How to Reference a Custom Permission in a Validation Rule (opens in a new tab), em inglês). Conceda de propósito, e a poucos.
• De uma data em diante, comparando CreatedDate com o dia em que a regra entrou no ar, quando “novo” significa “desde que começamos a aplicar isto”. Ao contrário de ISNEW(), ela continua verificando esses registros a cada gravação posterior, então vale o mesmo aviso: uma mudança pequena, como uma atualização de proprietário em lote, pode falhar num registro que se desviou da regra.

Acrescentando uma regra a registros que você já tem? Pense nas consequências antes de ligá-la. Todo registro existente agora precisa passar por ela na próxima gravação, e essa gravação pode vir de onde você não esperava: uma integração noturna, uma mudança de proprietário em lote, um resumo de totalização, uma atualização em massa a partir de uma visualização de lista. Quais delas vão esbarrar na regra, e o que acontece com esse job quando um registro falha? A seção Antes de ligar tem a sequência que eu uso.

Não reescreva o histórico para agradar à regra

E os vinte mil registros antigos? Se os dados estão errados e você sabe os valores certos, corrija. Mas já vi outro tipo de “conserto”: ninguém sabe a verdade histórica, só precisam que os registros passem, então os atualizam com valores que satisfazem a regra de hoje. Não gosto disso. Atualizar registros antigos para cumprir a regra muda o LastModifiedDate e destrói informação histórica importante, e inventar valores significa fingir que sabemos algo sobre o passado que não sabemos. Dê à regra um desvio para os registros anteriores a ela em vez de reescrever o histórico. Pode ser feio, mas é honesto.

Validação na interface não é validação de dados

Torne um campo obrigatório num layout de página e os usuários não conseguem salvar sem ele. Aí a integração noturna insere 50 mil registros. Ela usou sua página? Não. Nem a carga em massa, nem o cliente da API, nem o agente. Um requisito na interface protege aquela tela, não os dados. A validação de campo em formulários dinâmicos pode ser driblada do mesmo jeito. Então pergunte: por onde esses dados podem entrar? Lightning, o portal, o mobile, a integração, a API, uma carga em massa, Flow, Apex, um agente. Quanto mais portas há, menos confio numa regra que vigia só uma delas.

Degrau quatro: regras de duplicidade

Agora passamos da consistência dentro de um registro para a consistência entre registros. Acme Corporation, ACME Corp, Acme Inc.: quatro clientes ou um? Nenhuma regra de campo consegue responder a isso. As regras de correspondência definem como os registros são comparados; as regras de duplicidade decidem o que acontece quando uma provável duplicata é encontrada: permitir com um aviso, bloquear ou relatar. Você pode ter até cinco regras de duplicidade ativas por objeto e até três regras de correspondência em cada uma, e as chaves de correspondência estreitam cada comparação às 100 duplicatas mais prováveis (Things to Know About Duplicate Rules (opens in a new tab), em inglês).

O custo delas é o atrito. Se toda conta que um vendedor cria diz Possível duplicata encontrada, às vezes é exatamente o que você quer, e às vezes as pessoas aprendem a clicar sem ler. Registros legítimos podem se parecer, e uma integração pode precisar de um comportamento diferente do de uma pessoa. E o aviso é do próprio Salesforce: o alerta e a lista de possíveis duplicatas podem não combinar com uma tela personalizada que você construiu, e quando a gravação é headless (sem interface), uma integração, uma carga de dados, um agente, não há tela nenhuma onde mostrá-lo. Então decida como uma duplicata aparece em cada caminho: um aviso para uma pessoa, uma gravação bloqueada e um erro para a API, ou a opção Report (relatar) e os conjuntos de registros duplicados para alguém revisar depois. Boa arquitetura não é aplicação máxima; é a aplicação certa.

E verifique quais portas uma regra de duplicidade de fato vigia (Things to Know About Duplicate Rules (opens in a new tab), em inglês). Pela API e pelas ferramentas de importação de dados, ninguém vê o aviso: uma regra configurada para alertar simplesmente bloqueia a gravação. Alguns caminhos pulam as regras por completo: Quick Create, o botão Undelete (restaurar), uma mesclagem manual, registros adicionados pelo Lightning Sync ou pelo Einstein Activity Capture. E registros salvos no mesmo momento não são comparados entre si, só com registros que já estão no Salesforce. Carregue um arquivo com o mesmo cliente duas vezes, e as duas linhas podem passar. Uma regra de duplicidade é uma boa rede. Não é uma tranca na porta.

Conhecimento para o exame. As regras de duplicidade não comparam entre si registros salvos no mesmo momento, só com registros que já estão no Salesforce. Pela API e pelas ferramentas de importação não há alerta: uma duplicata que a regra pega simplesmente não é salva. E uma gravação e tudo o que ela dispara rodam como uma transação: se qualquer parte falhar, tudo é revertido.

Uma fronteira. Regras de duplicidade mantêm uma org limpa. Elas não resolvem a identificação na empresa. Se o Salesforce tem Acme Corporation, o ERP tem ACME-10382 e o faturamento tem o cliente 77193, uma regra de duplicidade não consegue lhe dizer que são a mesma empresa. Isso é dado mestre, capítulo 6.

Degrau cinco: automação

Algumas regras são complexas demais para os degraus de baixo: precisam de registros relacionados, de outro sistema, de registros dependentes, de um processo em várias etapas. Aí é Flow, Apex, às vezes lógica de integração. (Não Workflow Rules nem Process Builder; eles estão fora de suporte.) A automação é poderosa e mais cara: mais peças móveis, mais testes, mais tratamento de erros, mais formas de uma automação tropeçar em outra. E o código traz erros próprios. Se o tipo de campo consegue aplicar a regra, não escrevo Apex. Se uma regra de validação a diz com clareza, não construo um flow só porque o Flow está ali. Não resolva um problema de campo com um motor de processos.

Tudo ou nada: quando registros mudam juntos

Até aqui cada degrau protege uma gravação. Mas registros mudam juntos: uma entrega e seus itens, um pedido e suas linhas, um flow que atualiza três objetos. Aqui a plataforma lhe dá uma garantia forte. Uma gravação e tudo o que ela dispara, os triggers, os flows, as classes que eles chamam, rodam como uma transação: se qualquer parte falhar, tudo é revertido e nada é confirmado (Apex Transactions (opens in a new tab), em inglês). Você não fica com meia entrega.

O trabalho em massa é a exceção que você escolhe. Uma carga de dados ou um método Database do Apex pode permitir sucesso parcial: os registros bons são salvos, os ruins voltam com seus erros, e alguém precisa cuidar deles (DML Statements vs. Database Class Methods (opens in a new tab), em inglês). Isso costuma ser o certo para uma carga de um milhão de linhas, mas aí a consistência vira um processo: quem lê o arquivo de erros, e o que acontece com os registros que falharam?

E aí tem a questão do momento. Duas gravações no mesmo instante podem, as duas, passar por uma verificação que uma delas não passaria sozinha, depois da outra. Um flow que procura um pedido existente e depois cria um pode deixar passar dois, e acabamos de ver que as regras de duplicidade não comparam registros salvos ao mesmo tempo. Um campo marcado como Único, ou um ID externo, é verificado pela plataforma em toda gravação, então só um deles vence. É mais um motivo para empurrar a unicidade para baixo, até o campo. Bloqueios, contenção e novas tentativas são um assunto à parte; o capítulo 11, Transações, concorrência e confiabilidade, vai a fundo.

Empurre a regra para baixo, até onde ela não pertence mais

“O mais para baixo que for razoável” não significa “sempre o mais baixo”. Se um campo só é obrigatório quando uma oportunidade chega a determinado estágio, torná-lo obrigatório no esquema é errado; a regra é condicional, então uma regra de validação é o degrau certo. Se uma duplicata deve avisar uma pessoa, mas uma integração aprovada tem sua própria reconciliação, projete para os dois caminhos. O objetivo: a camada mais baixa que representa corretamente a regra de negócio.

Cada camada tem um custo

Click to enlarge

Este é o trade-off que quero que você veja. Tipos de campo e valores controlados são simples e fortes, mas só para o que um campo consegue expressar. Obrigatório e Único são brutos: depois de ligados, toda gravação precisa satisfazê-los. Regras de validação expressam condições mais ricas, mas podem bloquear edições em registros antigos e surpreender um deploy. Regras de duplicidade protegem entre registros, mas acrescentam atrito para usuários e integrações. A automação dá conta de qualquer coisa, mas faz você ser dono da orquestração, dos erros, dos testes e do desempenho. Não há camada de graça. Escolha a camada de cada regra sabendo como ela falha.

Antes de ligar

Acrescentar uma regra numa org existente é uma implantação, não uma caixa de seleção. Quantos registros a violam hoje, e por quê? Eles estão de fato errados? Conseguimos saber o valor certo? A regra é verdadeira historicamente, ou só daqui para frente? Quais integrações, testes e automações vão esbarrar nela? Uma boa sequência: medir, limpar o que você consegue provar que está errado, delimitar a regra, acrescentar um desvio deliberado para o histórico legítimo, testar cada caminho de gravação, e então aplicar. Medir e limpar são disciplinas próprias, perfilamento, padronização, monitoramento, stewardship (curadoria), e o capítulo 5, Qualidade e governança de dados, trata delas. Muito melhor do que marcar uma caixa na sexta-feira e descobrir as consequências no sábado à noite.

Além do exame: o que a IA muda. Um agente consegue criar registros mais rápido do que qualquer pessoa, e registros ruins com a mesma rapidez. “Os usuários sabem que não devem fazer isso” não é proteção quando o usuário é um agente. Coloque as regras importantes na camada de dados, onde todo gravador as encontra, para que o agente não precise lembrar das regras não escritas da empresa.

Steve Trucking: proteja a entrega

Pegue uma entrega. O status dela vem de um vocabulário só: uma lista de opções, restrita. A referência de pedido do Parceiro varejista precisa ser única por parceiro, então é um ID externo, marcado como único, usado para fazer upsert do manifesto. O horário real da entrega é obrigatório quando o status é Entregue: uma regra de validação, limitada a essa mudança. Uma parada de instalação não pode ser fechada até o checklist estar completo e as fotos obrigatórias terem sido tiradas (para uma lava-louças, a mangueira de água, a de escoamento e o nivelamento): uma regra de validação, ou automação se precisar verificar as fotos guardadas fora da plataforma. O mesmo pedido chegando duas vezes num manifesto reenviado é pego pelo ID externo; dois pedidos diferentes que se parecem são uma questão de correspondência.

Repare que não falei “coloque tudo num flow”. Cada regra fica no seu próprio degrau. Para cada regra, pergunte: qual é a camada mais baixa que a aplica corretamente em todo caminho de gravação que importa?

O que um arquiteto decide aqui

• Em qual degrau cada regra pertence: tipo de campo, vocabulário controlado, obrigatório ou único, regra de validação, regra de duplicidade ou automação.
• Quais caminhos de gravação precisam ser protegidos: interface, portal, mobile, integrações, cargas em massa, APIs, automação e agentes.
• Se uma regra nova vale para registros históricos, ou se limita a dados novos e alterados com um desvio para o passado.
• Se os dados ruins existentes podem ser corrigidos a partir de evidências, em vez de reescritos para passar.
• Quanto atrito, complexidade e manutenção uma regra vale.

Dados limpos não vêm de pedir às pessoas que insiram dados bons. Vêm de uma arquitetura que torna o certo fácil, o errado difícil, e as regras importantes difíceis de contornar. A seguir, juntamos o capítulo num recorte da Steve Trucking.

Para saber mais

• Salesforce Help, How to Reference a Custom Permission in a Formula, Workflow Rule, or Validation Rule (opens in a new tab) e Roll-Up Summary Field (opens in a new tab) (em inglês), consultado em 2026-10-13.
• Salesforce Help, Picklist Limitations (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Help, Validation Rule Considerations (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (em inglês), consultado em 2026-10-13: os limites, os caminhos em que as regras não rodam, gravações por API e importação bloqueadas sem alerta, gravações simultâneas não comparadas.
• Apex Developer Guide, Apex Transactions (opens in a new tab) e DML Statements vs. Database Class Methods (opens in a new tab) (em inglês), consultado em 2026-10-13: uma transação é revertida como uma unidade; os métodos Database podem permitir sucesso parcial.
• Salesforce Help, Workflow Rules & Process Builder End of Support (opens in a new tab) (em inglês), consultado em 2026-10-02.