Manter os dados consistentes

🌐 Também em 28 idiomas

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · 繁體中文 · 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 com IA. Ainda não revisto 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 sustenta-se 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?

Toda a gente quer dados limpos. Nunca entrei numa reunião de requisitos em que alguém dissesse: «O que gostaríamos mesmo era de dados inconsistentes.» O desacordo vem depois: onde aplicamos as regras? No ecrã? Um campo obrigatório? Uma lista de opções, uma regra de validação, uma regra de duplicados, um flow, Apex? Todos ajudam. Não são intercambiáveis, e cada camada tem um custo.

A 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 escreverem qualquer coisa para limpar depois com automação. Se dois registos nunca podem partilhar um identificador, não conte com alguém a reparar nisso num relatório. Se uma regra tem de valer quer o registo venha de um ecrã, 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 fica a regra, mais difícil é contorná-la. Chamo a isto 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 estado de uma entrega um campo de texto e vai ter 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 partilham a lista (o módulo 6 tem os pormenores).

Mas não use uma lista de opções só para impedir as pessoas de escrever. É mesmo um valor, ou outra entidade? Nove centros de distribuição com um nome cada podem parecer uma lista de opções; nove com moradas, gestores, capacidade e camiões são registos. A regra deve reforçar o modelo, não compensar um mau modelo. 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 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 cada camião tem um número de frota desde o dia em que é criado, e nenhum par de camiões partilha um, as duas caixas exprimem regras de negócio reais. Isso é consistência forte.

Mas, depois de a plataforma aplicar uma regra, não lhe importa que o seu processo tenha uma exceção à terça à tarde. Uso este exemplo nas aulas há anos. Um objeto existe há algum tempo, com muitos registos. Alguém acrescenta um campo e marca Obrigatório. Testa criar um registo: funciona lindamente. Depois, sábado à noite, deploy, os testes correm, e uma classe de teste antiga cria o objeto sem o campo novo. Bum. Ou alguém edita um registo antigo de antes de o campo existir. Ou a integração envia o mesmo payload que envia há cinco anos. Bum. «Mas não tocámos naquele campo.» A plataforma não quer saber: mudou o contrato do que é um registo válido. Uma regra nova não afeta só os dados novos; muda o que pode fazer com os dados antigos.

Degrau três: regras de validação

As regras de validação deixam-nos dizer coisas muito mais ricas. Se o estado é Entregue, a hora real da entrega tem de estar preenchida. Se a paragem é uma instalação, a checklist tem de estar completa antes de a paragem poder ser fechada. Correm quando o registo é gravado, por isso protegem o registo quer tenha sido gravado a partir 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 tem de proteger o registo, ponha-a onde todas as gravações a encontram.

Também têm dentes. Essa é a sua força e o seu custo.

O problema dos registos antigos

É aqui que fica feio. Tem um milhão de registos, e hoje acrescenta uma regra: a hora da entrega não pode ser anterior à saída da rota. Sensato. Mas vinte mil registos antigos violam-na, graças a uma migração de há sete anos. Um utilizador abre um deles e muda o telefone. Gravar. A regra dispara. «Mudei um número de telefone. Porque é que me está a falar de uma hora de entrega de 2019?» Pergunta justa.

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

Mas um registo não muda só quando uma pessoa o edita, e muitos dos motivos estão fora do seu controlo. A integração atualiza o estado durante a noite. Um flow carimba uma data. Um gestor reatribui um território e o proprietário muda em dez mil registos. Alguém edita um item de entrega, o resumo de totalização na entrega é recalculado, e isso guarda a entrega, por isso a regra de validação da entrega dispara para um utilizador que nunca lhe tocou (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. Por isso, para cada regra nova, pergunte: esta regra deve aplicar-se àquela gravação?

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

• Sempre, em todas as gravações. Certo quando a regra é de facto sobre o registo e os dados antigos passam. Mas saiba o que «todas as gravações» significa: um job em lote que só muda o proprietário, ou qualquer pequena edição em qualquer campo do registo, também tem de passar por ela.
• Só para registos novos, com ISNEW(). A regra verifica o registo uma vez, quando é criado, e nunca mais. O passado fica como estava, mas o futuro também: uma edição posterior pode fazer um registo novo violar a regra, e ninguém o vai impedir. Se isso importa, combine-a com a seguinte.
• Só quando os campos de que trata mudam, com ISCHANGED(). Editar o número de telefone não acorda a regra da hora da entrega.
• Não para certos autores da gravação. Uma permissão personalizada, verificada na fórmula como $Permission, deixa passar o utilizador 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-a de propósito, e a poucos.
• De uma data em diante, comparando CreatedDate com o dia em que a regra entrou em produção, quando «novo» significa «desde que começámos a aplicar isto». Ao contrário de ISNEW(), continua a verificar esses registos em cada gravação posterior, por isso vale o mesmo aviso: uma mudança pequena, como uma atualização de proprietário em lote, pode falhar num registo que se desviou da regra.

Vai acrescentar uma regra a registos que já tem? Pense nas consequências antes de a ligar. Cada registo existente tem agora de passar por ela na próxima gravação, e essa gravação pode vir de onde 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 vista de lista. Quais delas vão esbarrar na regra, e o que acontece a esse job quando um registo falha? A secção Antes de ligar tem a sequência que uso.

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

E os vinte mil registos antigos? Se os dados estão errados e sabe os valores certos, corrija-os. Mas já vi outro tipo de «correção»: ninguém sabe a verdade histórica, só precisam que os registos passem, por isso atualizam-nos com valores que satisfazem a regra de hoje. Não gosto disso. Atualizar registos 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 registos anteriores a ela em vez de reescrever o histórico. Pode ser feio, mas é honesto.

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

Torne um campo obrigatório num layout de página e os utilizadores não conseguem gravar sem ele. Depois a integração noturna insere 50 mil registos. Usou a sua página? Não. Nem a carga em massa, nem o cliente da API, nem o agente. Um requisito na interface protege aquele ecrã, não os dados. A validação de campo em formulários dinâmicos pode ser contornada da mesma forma. Por isso pergunte: por onde podem entrar estes dados? 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 duplicados

Agora passamos da consistência dentro de um registo para a consistência entre registos. 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 registos são comparados; as regras de duplicados decidem o que acontece quando é encontrado um provável duplicado: permitir com um aviso, bloquear ou reportar. Pode ter até cinco regras de duplicados ativas por objeto e até três regras de correspondência em cada uma, e as chaves de correspondência estreitam cada comparação aos 100 duplicados mais prováveis (Things to Know About Duplicate Rules (opens in a new tab), em inglês).

O seu custo é o atrito. Se cada conta que um comercial cria diz Possível duplicado encontrado, às vezes é exatamente o que quer, e às vezes as pessoas aprendem a clicar sem ler. Registos legítimos podem parecer-se, 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 duplicados podem não combinar com um ecrã personalizado que construiu, e quando a gravação é headless (sem interface), uma integração, uma carga de dados, um agente, não há ecrã nenhum onde o mostrar. Por isso decida como um duplicado aparece em cada caminho: um aviso para uma pessoa, uma gravação bloqueada e um erro para a API, ou a opção Report (comunicar) e os conjuntos de registos duplicados para alguém rever depois. Boa arquitetura não é aplicação máxima; é a aplicação certa.

E verifique que portas uma regra de duplicados vigia de facto (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 saltam as regras por completo: Quick Create, o botão Undelete (restaurar), uma fusão manual, registos acrescentados pelo Lightning Sync ou pelo Einstein Activity Capture. E os registos guardados no mesmo momento não são comparados entre si, só com registos que já estão no Salesforce. Carregue um ficheiro com o mesmo cliente duas vezes, e as duas linhas podem passar. Uma regra de duplicados é uma boa rede. Não é uma fechadura na porta.

Conhecimento para o exame. As regras de duplicados não comparam entre si registos guardados no mesmo momento, só com registos que já estão no Salesforce. Pela API e pelas ferramentas de importação não há alerta: um duplicado que a regra apanha simplesmente não é guardado. E uma gravação e tudo o que ela desencadeia correm como uma transação: se qualquer parte falhar, tudo é revertido.

Uma fronteira. As regras de duplicados mantêm uma org limpa. Não resolvem a identificação na empresa. Se o Salesforce tem Acme Corporation, o ERP tem ACME-10382 e a faturação tem o cliente 77193, uma regra de duplicados não lhe consegue dizer que são a mesma empresa. Isso são dados mestres, capítulo 6.

Degrau cinco: automação

Algumas regras são complexas demais para os degraus de baixo: precisam de registos relacionados, de outro sistema, de registos 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; já não têm 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 noutra. 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 os registos mudam juntos

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

O trabalho em massa é a exceção que escolhe. Uma carga de dados ou um método Database do Apex pode permitir sucesso parcial: os registos bons são guardados, os maus voltam com os seus erros, e alguém tem de tratar 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 torna-se um processo: quem lê o ficheiro de erros, e o que acontece aos registos que falharam?

E depois há 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 uma encomenda existente e depois cria uma pode deixar passar duas, e acabámos de ver que as regras de duplicados não comparam registos guardados ao mesmo tempo. Um campo marcado como Único, ou um ID externo, é verificado pela plataforma em todas as gravações, por isso só um deles ganha. É mais um motivo para empurrar a unicidade para baixo, até ao campo. Bloqueios, contenção e novas tentativas são um assunto à parte; o capítulo 11, Transações, concorrência e fiabilidade, vai a fundo.

Empurre a regra para baixo, até onde já não pertence

«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 determinada fase, torná-lo obrigatório no esquema é errado; a regra é condicional, por isso uma regra de validação é o degrau certo. Se um duplicado deve avisar uma pessoa, mas uma integração aprovada tem a 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 veja. Tipos de campo e valores controlados são simples e fortes, mas só para o que um campo consegue exprimir. Obrigatório e Único são brutos: depois de ligados, todas as gravações têm de os satisfazer. As regras de validação exprimem condições mais ricas, mas podem bloquear edições em registos antigos e surpreender um deploy. As regras de duplicados protegem entre registos, mas acrescentam atrito para utilizadores e integrações. A automação trata de qualquer coisa, mas obriga-o a 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 falha.

Antes de ligar

Acrescentar uma regra numa org existente é uma implementação, não uma caixa de verificação. Quantos registos a violam hoje, e porquê? Estão de facto errados? Conseguimos saber o valor certo? A regra é verdadeira historicamente, ou só daqui para a frente? Que integrações, testes e automações vão esbarrar nela? Uma boa sequência: medir, limpar o que 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 só então aplicar. Medir e limpar são disciplinas próprias, perfilagem, normalização, monitorização, stewardship (curadoria), e o capítulo 5, Qualidade e governação 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 registos mais depressa do que qualquer pessoa, e registos maus com a mesma rapidez. «Os utilizadores sabem que não devem fazer isso» não é proteção quando o utilizador é um agente. Ponha as regras importantes na camada de dados, onde todos os que gravam as encontram, para que o agente não tenha de se lembrar das regras não escritas da empresa.

Steve Trucking: proteja a entrega

Pegue numa entrega. O seu estado vem de um só vocabulário: uma lista de opções, restrita. A referência de encomenda do Parceiro retalhista tem de ser única por parceiro, por isso é um ID externo, marcado como único, usado para fazer upsert do manifesto. A hora real da entrega é obrigatória quando o estado é Entregue: uma regra de validação, limitada a essa mudança. Uma paragem de instalação não pode ser fechada até a checklist estar completa e as fotografias obrigatórias terem sido tiradas (para uma máquina de lavar loiça, a mangueira de água, a de escoamento e o nivelamento): uma regra de validação, ou automação se tiver de verificar as fotografias guardadas fora da plataforma. A mesma encomenda a chegar duas vezes num manifesto reenviado é apanhada pelo ID externo; duas encomendas diferentes que se parecem são uma questão de correspondência.

Repare que não disse «ponha 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 todos os caminhos de gravação que importam?

O que um arquiteto decide aqui

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

Dados limpos não vêm de pedir às pessoas que introduzam 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.