Campos também são arquitetura

🌐 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 6 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Escolha o objeto certo · Próximo: Relacionamentos têm consequências

A pergunta que este módulo responde: Como o Salesforce deve representar fisicamente cada dado?

Criar um campo leva mais ou menos um minuto. Novo campo, escolha um tipo, dê um nome, Avançar, Avançar, Salvar. É exatamente por isso que os campos não são tratados como arquitetura.

Entre numa org que existe há dez anos e abra a Conta. Quinhentos campos. Status2__c, Legacy_Status__c, Old_Status__c, Status_New__c. Três números de cliente diferentes. Uma caixa de seleção que ninguém exclui porque ninguém sabe qual integração ainda a usa. Criar o campo levou um minuto. Conviver com ele leva anos. Então a ideia deste módulo é simples: um campo é uma decisão de arquitetura. Nem sempre uma grande, mas todo campo codifica algo sobre o significado, o comportamento, a identificação ou a qualidade dos dados e, como os objetos, campos são fáceis de acrescentar e surpreendentemente difíceis de tirar.

O que esse dado realmente significa?

No capítulo 2 demos atributos às nossas entidades: uma Entrega tem uma janela agendada, um Caminhão tem um chassi (VIN). Agora os implementamos, e é aqui que as pessoas pulam direto para “campo de texto”. Calma. Antes do tipo, quero saber o que o dado significa. É um número, ou um identificador que por acaso tem dígitos? Uma data, ou um momento no tempo? Texto livre, ou um de um conjunto aprovado? Digitado por uma pessoa, ou de propriedade de outro sistema? Pode mudar? Precisa ser único? Pode faltar? Deveria sequer ser armazenado, ou calculado? Essas não são perguntas de Setup. São perguntas de arquitetura de dados, e o tipo de campo vem depois de respondê-las.

Um número nem sempre é um número

A Steve Trucking dá a cada caminhão um número de frota, digamos 001247. Campo de número? Provavelmente não. Somamos números de frota? O caminhão 1247 menos o caminhão 1246 é um caminhão? É um identificador que por acaso contém dígitos, e um campo de Número ainda jogaria fora os zeros à esquerda. O mesmo vale para códigos postais, códigos de produto, números de conta e números de rastreamento. A aparência do valor não diz o que ele significa. Escolha o tipo pelo comportamento de que você precisa, não pela cara dos dados de exemplo.

Um humano precisa identificá-lo?

Todo objeto personalizado ganha um campo Nome, e a primeira decisão é texto ou numeração automática. Pergunto: um humano precisa identificar esta coisa? As pessoas conhecem um Parceiro varejista pelo nome e um caminhão pelo número de frota. Mas um manifesto que o sistema gera toda noite? Ninguém deveria estar digitando “Manifesto 10-02 Número 3” porque o Salesforce exigiu um Nome. Dê a ele uma numeração automática. Só não confunda esse Nome gerado com a identificação do registro: a numeração automática ajuda os usuários, o ID do Salesforce identifica o registro, e a referência de manifesto do próprio Parceiro varejista pode identificar a mesma coisa entre sistemas. Três trabalhos diferentes.

A tela de detalhes

Escolha um tipo, clique em Avançar, e o Setup pede os detalhes. É nesta tela que a maioria das decisões deste módulo é realmente tomada, quase sempre com pressa.

New Custom Field (Novo campo personalizado), passo 2: os detalhes (captura de tela, 2026-10-12). Tamanho real

Duas caixas parecem iguais e fazem trabalhos diferentes. Description (Descrição) é para as pessoas que mantêm a org, e agora para as ferramentas de IA que a leem: o que o campo significa, quem é o dono, de onde ele vem. Help Text (Texto de ajuda) é para o usuário na tela: o que digitar aqui. Preencha as duas. Depois vêm Required (Obrigatório), Unique (Único) e External ID (ID externo), e cada um deles merece sua própria seção. Abaixo deles, Default Value (Valor padrão) pode ser uma fórmula, para que um registro novo comece com um valor sensato em vez de em branco.

Obrigatório é uma decisão maior do que parece

Há uma caixinha no assistente de campo chamada Obrigatório, e como vimos no capítulo 1, ela pode ser uma bomba-relógio. Você tem um objeto há cinco anos e dois milhões de registros, e agora alguém decide que um campo novo sempre precisa ter valor. E os dois milhões de registros anteriores a ele? As integrações que não o enviam? A automação que cria o registro antes de o valor ser conhecido? O processo em que o valor só aparece três etapas depois?

“Obrigatório” soa como uma decisão de qualidade de dados, e às vezes é. Mas quando um valor passa a ser conhecido faz parte do processo de negócio. Então não marque Obrigatório porque alguém diz “sempre queremos isso”. Pergunte quando ele é conhecido, quem o fornece, e o que acontece quando não é. Vamos colocar isso na escada completa de consistência no módulo 7.

Único também significa algo

Se marco um campo como único, estou fazendo uma afirmação sobre o negócio: não “normalmente não se repete”, mas “dois registros nunca podem ter este valor”. Isso é forte. E a tela obriga você a decidir mais uma coisa: “ABC” e “abc” são o mesmo valor ou valores diferentes? Não diferenciar maiúsculas de minúsculas é o padrão mais seguro para qualquer coisa que uma pessoa digita. A regra de chaves do capítulo 2, única, imutável, sem significado, nunca dado pessoal, vale aqui. Se alguém me diz que o e-mail do funcionário é único, começo a perguntar: ele pode mudar, alguém pode sair e voltar, endereços podem ser reutilizados, o que acontece depois de uma aquisição? O e-mail pode ser útil, até único hoje. Isso não o torna uma boa identificação.

IDs externos: identificação através da fronteira

É aqui que os IDs externos mostram seu valor. A tela descreve bem: o campo vira “the unique record identifier from an external system” (o identificador exclusivo do registro vindo de um sistema externo). O ERP tem o cliente 873492; o Salesforce tem seu próprio ID de registro. Quando o ERP envia uma atualização, como sabemos a qual registro ela pertence? Marque um campo como ID externo e uma integração pode fazer upsert por ele: cria o registro se ele não existir, atualiza se existir (Upsert a Record Using an External ID (opens in a new tab), em inglês). E quando você carrega registros filhos, pode apontar para o pai pelo ID externo dele em vez de consultar primeiro o ID do Salesforce. Gosto de dizer que você deixa o Salesforce fazer a busca por você. Muito poderoso.

Repare que o número do ERP não vira a identificação do registro Salesforce. Ele é um atributo, e um registro pode carregar vários: um ID de cliente do ERP, um ID legado, o ID de um parceiro. Tudo bem. Uma entidade de negócio pode ser conhecida de formas diferentes por vários sistemas. A pergunta de arquitetura é qual sistema é dono de cada identificador, e que promessa ele faz: marque-o como único só se o negócio realmente garantir isso.

Tipo de campo por tipo de campo

Agora, os tipos em si. Abra New Field (Novo campo) em qualquer objeto e o Setup mostra a lista inteira, agrupada do jeito que vou percorrê-la: os campos que o Salesforce calcula para você, os campos de relacionamento e, depois, os tipos de dados.

Setup, New Custom Field, passo 1: os tipos de dados (captura de tela, 2026-10-12). Tamanho real

Eis a lista inteira num relance, com a única coisa que eu gostaria que você lembrasse de cada um.

Grupo	Tipo	Lembre
Calculados	Numeração automática (Auto Number)	Até 30 caracteres, 20 deles de prefixo ou sufixo; um rótulo para pessoas, não a identificação do registro
	Fórmula (Formula)	Calculada na leitura, não armazenada; 3.900 caracteres
	Resumo de totalização (Roll-Up Summary)	Contagem, soma, mínimo ou máximo dos detalhes; só em mestre-detalhes
Relacionamentos	Pesquisa, mestre-detalhes, pesquisa externa (Lookup, Master-Detail, External Lookup)	Módulo 7
Dados	Caixa de seleção (Checkbox)	Verdadeiro ou falso, com um padrão que você escolhe; nulo ainda pode aparecer em fluxos
	Número, porcentagem, moeda (Number, Percent, Currency)	Regras de arredondamento; zeros à esquerda descartados; 15 casas decimais
	Data, data/hora, hora (Date, Date/Time, Time)	Um dia, um momento ou uma hora do dia; momentos são armazenados em UTC
	Email, telefone, URL (Email, Phone, URL)	Formatados e verificados ao salvar: 80, 40 e 255 caracteres
	Geolocalização, endereço (Geolocation, Address)	Campos compostos que custam mais de um campo: 3 e 9
	Lista de opções, seleção múltipla (Picklist, Multi-Select)	Um vocabulário controlado, com um administrador como dono
	Texto, área de texto, longo, rich, criptografado (Text, Text Area, Long, Rich, Encrypted)	Até 255, no registro e indexável; acima disso, sem índice nem filtro

Os campos que o Salesforce calcula

A numeração automática (Auto Number) atribui o próximo número de uma sequência a cada registro novo, num formato que você define, como T-{000000}. Use quando um humano precisa de um identificador amigável e ninguém deveria ter de inventar um. O valor inteiro tem até 30 caracteres, e 20 deles são reservados para o prefixo ou o sufixo. Só lembre do capítulo 2: é um rótulo para pessoas, não a identificação do registro, e os números nem sempre são estritamente sequenciais.

Os campos de fórmula (Formula) calculam um valor a partir de outros campos. São poderosos, e são calculados quando o registro é lido, não quando é salvo, então não há nada armazenado para ficar desatualizado. Você escolhe o que a fórmula retorna: caixa de seleção, moeda, data, data/hora, número, porcentagem, texto ou hora.

New Custom Field, fórmula: escolhendo o tipo de retorno (captura de tela, 2026-10-12). Tamanho real

Depois você escreve a fórmula em si, com campos, operadores e funções, e verifica a sintaxe. Repare no botão Use Formula Assistant (Usar o assistente de fórmula): agora a IA da Salesforce ajuda você a escrever a fórmula. Use, e depois leia o que ela escreveu. O dono da fórmula é você, não o assistente.

O editor de fórmulas, com o Formula Assistant (captura de tela, 2026-10-12). Tamanho real Uma fórmula pode ter até 3.900 caracteres, e não pode passar de 15.000 bytes quando salva ou compilada; uma fórmula longa pode ser dividida em vários campos de fórmula que fazem referência uns aos outros. Áreas de texto longo, campos criptografados e campos Description não podem ser usados nelas.

Os campos de resumo de totalização (Roll-Up Summary) ficam no mestre e contam, somam, ou pegam o mínimo ou o máximo dos registros de detalhe. Só funcionam num relacionamento mestre-detalhes, o que é um dos maiores motivos para escolher mestre-detalhes. Vamos voltar a eles, e aos seus limites, no módulo 7.

Armazenado ou derivado?

Precisamos sequer armazenar este valor? Se tenho quantidade e preço unitário, alguém, ou alguma automação, precisa manter um total? Talvez uma fórmula deva derivá-lo: uma fonte única para o cálculo, recalculada quando é lida, então mude a quantidade e a resposta acompanha. As fórmulas têm seus próprios limites (tamanho ao salvar e tamanho exibido; Formula Field Limits and Restrictions (opens in a new tab), em inglês), e as complexas ficam difíceis de manter.

Mas às vezes o negócio não quer a resposta de hoje. Quer a resposta como era. Se a regra de desconto muda no ano que vem, a fatura do ano passado deveria de repente mostrar outro valor? Claro que não. Então a pergunta não é “o Salesforce consegue calcular isto?” É “isto é um cálculo atual ou um fato histórico?” Fatos históricos são armazenados.

Os campos de relacionamento

Os relacionamentos de pesquisa (Lookup), mestre-detalhes (Master-Detail) e pesquisa externa (External Lookup) também são campos, e é neles que as linhas do seu modelo viram realidade. A pesquisa é o vínculo solto; o mestre-detalhes amarra a vida, a propriedade e a segurança do filho ao pai; a pesquisa externa alcança um objeto externo do módulo 4, fazendo a correspondência pelo ID externo dele. Escolher entre eles é uma decisão grande o bastante para ganhar um módulo próprio.

Caixa de seleção

Uma caixa de seleção (Checkbox) é o campo mais simples que existe: verdadeiro ou falso, marcada ou desmarcada. É perfeita para um fato de sim ou não sobre o registro: Está ativo, Instalação necessária, Recebido com assinatura. Quando você cria uma, o Salesforce obriga você a escolher o valor padrão, marcada ou desmarcada, e essa é uma decisão de verdade: é com ele que todo registro novo começa, inclusive os registros que uma integração cria sem enviar o campo. Relatórios e visualizações de lista filtram como True e False; as ferramentas de importação e a exportação semanal mostram como 1 e 0.

Uma armadilha para conhecer. O campo no registro tem dois valores, mas a automação em volta dele pode ter um terceiro. Num fluxo, uma variável de caixa de seleção que nunca foi definida é nula, não falsa, e salvá-la num registro falha (Trailblazer Community (opens in a new tab), em inglês; veja também o problema conhecido da Salesforce W-11208535 (opens in a new tab)). Escolha um padrão sensato, e faça seus fluxos e seu código tratarem o nulo de propósito.

Número, porcentagem e moeda

O Número (Number) armazena um número real e descarta qualquer zero à esquerda, que é exatamente por isso que um número de frota como 001247 não é um Número. O Salesforce arredonda campos de número a partir da metade, para longe do zero: 12,345 vira 12,35, e −12,345 vira −12,35. E em campos de mesclagem, ele arredonda conforme a localidade do usuário, não conforme as casas decimais que você definiu no campo.

A Porcentagem (Percent) armazena um decimal e mostra uma porcentagem: digite 0,10 e você vê 10%. Os valores perdem precisão depois de 15 casas decimais.

A Moeda (Currency) é formatada para dinheiro, e numa org com várias moedas carrega o código da moeda e pode usar taxas de câmbio; com o gerenciamento avançado de moedas (opens in a new tab) (em inglês), as oportunidades podem usar taxas de câmbio datadas, a taxa do período em que o negócio foi fechado. Só as oportunidades e o que gira em torno delas (produtos, cronogramas, divisões e seus relatórios) usam taxas datadas; campos de moeda em outros objetos mantêm a taxa estática única. Cuidado com o arredondamento: sem casas decimais, o Salesforce simplesmente trunca (23,5 vira 23); com uma ou mais, arredonda a partir da metade, para longe do zero.

Data, data/hora e hora

Três tipos, três significados diferentes. Uma Data (Date) é um dia: um contrato vence numa data. Uma Data/hora (Date/Time) é um momento: a entrega chegou às 9h42 daquela manhã. Uma Hora (Time) é uma hora do dia, sem data nenhuma: a loja abre às 7h00, todo dia.

A armadilha é o momento. O Salesforce armazena valores de data/hora em GMT (UTC). A hora que um usuário digita é lida no fuso horário dele, convertida e armazenada; quando alguém a lê, ela é convertida de novo para o fuso horário de quem lê. Na maior parte do tempo, é exatamente o que você quer. Mas eis o exemplo que dou em aula: uma coordenadora em Los Angeles registra uma entrega tarde no domingo à noite, às 22h, horário do Pacífico. Por baixo, o Salesforce armazenou segunda de manhã, 5h GMT. Um relatório agrupado por dia em outro fuso horário, ou uma integração lendo o valor bruto, pode colocar aquela entrega de domingo na segunda. “O dia em que aconteceu” depende de qual relógio você consulta. Fique de olho nos fusos horários dos usuários, e decida qual deles o negócio quer dizer.

E cuidado ao compará-los. Por baixo, uma data/hora é um número grande: o Apex a lê como o número de milissegundos desde 1º de janeiro de 1970, 00:00:00 GMT (Datetime Class (opens in a new tab), em inglês). É um momento preciso, não um dia. Então perguntar se duas datas/horas são iguais (==) quase nunca faz o que você quer: 9h42min00 e 9h42min01 não são iguais, e “segunda-feira” e um momento qualquer da segunda também não. Em vez disso, peça um intervalo: a partir do início (>=) e até o fim (<=). “Toda entrega de segunda” é toda entrega >= segunda 00:00 e <= segunda 23:59:59, no fuso horário que você decidiu que o negócio quer dizer.

E uma curiosidade: o Salesforce não consegue armazenar qualquer data. As datas válidas vão de 1º de janeiro de 1700 até 31 de dezembro de 4000, e o Salesforce dá o mesmo intervalo para datas e datas/horas (Data Import Dates (opens in a new tab), em inglês). Até os extremos são momentos em GMT, então para um usuário no horário do Pacífico o primeiro valor válido é 16h de 31 de dezembro de 1699. A data de fundação da sua sociedade histórica pode não caber. E o truque clássico de “sem data de fim”, 31 de dezembro de 9999, é rejeitado; se você precisa de um marcador no futuro distante, ele tem de estar no ano 4000 ou antes.

Email, telefone e URL

Estes são os campos formatados, e eles fazem mais do que guardar caracteres. O Email guarda até 80 caracteres e tem o formato verificado; em contatos e leads, clicar nele começa um e-mail para aquele endereço. O Telefone (Phone) guarda até 40 caracteres, é formatado como número de telefone e vira clique para discar quando a org tem um sistema de telefonia conectado. A URL guarda até 255 caracteres e abre como link. É a plataforma dando comportamento de graça, e é por isso que eu nunca guardaria um número de telefone num campo de texto simples.

As integrações também são verificadas. Um valor que não bate com o formato do campo, como um endereço de e-mail malformado, falha na validação, e o registro inteiro é rejeitado, não só aquele campo. Então, quando os dados do sistema de origem estão bagunçados, limpe-os antes de chegarem, ou planeje para os registros que não vão carregar.

Geolocalização e endereço

A Geolocalização (Geolocation) guarda uma latitude e uma longitude. Por baixo, um campo chamado Location__c são na verdade dois valores que você pode ler e definir separadamente, Location__Latitude__s e Location__Longitude__s. E você pode consultar por ele: as funções DISTANCE e GEOLOCATION do SOQL encontram registros dentro de um raio, ou os ordenam pela distância. “Toda entrega aberta num raio de 25 milhas deste caminhão” é uma única consulta: WHERE DISTANCE(Location__c, GEOLOCATION(33.45, -112.07), 'mi') < 25 (Location-Based SOQL Queries (opens in a new tab), em inglês). O Endereço (Address) guarda um endereço inteiro, rua, cidade, estado ou província, código postal e país, e os usuários podem buscar um endereço e ter as partes preenchidas.

Os dois são campos compostos: um campo na tela, vários por baixo. E eles custam mais de um campo no limite do seu objeto: uma Geolocalização conta como três campos personalizados, e um Endereço conta como nove. Num objeto que já está lotado, isso importa.

Lista de opções e seleção múltipla

Uma lista de opções (Picklist) controla o que os usuários podem inserir: um valor de uma lista que você define. Status? Lista de opções, provavelmente. Mas os valores são metadados, e um administrador tem de adicioná-los ou alterá-los. Então ainda pergunto quem é dono dos valores, com que frequência mudam, se vários objetos precisam da mesma lista, se os valores carregam informação própria, e se outro sistema é dono do vocabulário.

Onde os valores vivem também é uma decisão. Quando uma lista é usada uma vez, num campo, mantenha os valores no próprio campo, no objeto; é o que o Salesforce faz por padrão. Mas quando o mesmo conjunto de valores começa a aparecer em vários lugares, uma Região na conta, na entrega e no armazém, promova-o a um conjunto de valores global antes que as cópias se distanciem. Um conjunto de valores global mantém uma lista para todos eles, com até 1.000 valores, ativos e inativos somados (Picklist Limitations (opens in a new tab), em inglês). A própria descrição do Setup diz por que isso importa: o conjunto de valores “is restricted so users can’t add unapproved values through the API” (é restrito para que os usuários não possam adicionar valores não aprovados pela API). Uma lista, um dono, e nenhuma integração enfiando uma grafia nova.

Esse último ponto é a diferença entre restrita e não restrita. Numa lista de opções restrita, só os valores que um administrador definiu são permitidos, venham de onde vierem: um usuário, uma importação ou uma integração que envie qualquer outra coisa recebe um erro, “bad value for restricted picklist field”, e o registro não é salvo. Numa lista de opções não restrita, os usuários ainda escolhem da lista na tela, mas a API, as importações e a automação podem enviar qualquer valor, e o Salesforce o salva e o adiciona como valor inativo (Picklist Limitations (opens in a new tab); Create a Custom Picklist Field (opens in a new tab), em inglês). É assim que uma org acaba com “Delivered”, “delivered” e “Dlvrd”. Conjuntos de valores globais são sempre restritos. Meu padrão é restrita; não restrita é uma escolha deliberada para quando outro sistema é realmente o dono dos valores, e aí alguém fica responsável por limpar os inativos.

Setup, Picklist Value Sets (Conjuntos de valores de lista de opções): um novo conjunto de valores global (captura de tela, 2026-10-12). Tamanho real

Uma lista de opções de seleção múltipla (Multi-Select Picklist) deixa o usuário escolher vários valores, armazenados juntos e separados por ponto e vírgula. Prática na tela, desajeitada em todo o resto: mais difícil de filtrar, de relatar e de integrar, e não pode ser usada no filtro de um resumo de totalização. Vários valores para um registro normalmente significam a lição do capítulo 2: há um objeto filho tentando sair.

Uma lista de opções também tem um valor a mais do que os que você definiu: em branco. Um registro pode ficar sem nada selecionado, e isso pega as pessoas. Numa fórmula ou regra de validação você não consegue testar uma lista de opções só com ISBLANK; você escreve ISBLANK(TEXT(Field__c)), ou ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), em inglês). Então decida o que “sem valor” significa para cada lista de opções: é permitido, e o que significa quando acontece? Depois faça suas fórmulas, regras de validação e filtros lidarem com isso.

E às vezes um atributo é, na verdade, uma entidade. Alguém pede uma lista de opções de centros de distribuição. São nove. Fácil. Aí descobrimos que cada um tem endereço, gerente, horário, capacidade, região e caminhões. Isso não é uma lista de opções; é uma coisa. Não transforme uma entidade numa lista de opções só porque ainda não há muitas delas. Parece ótimo no primeiro ano e péssimo no quinto. (O módulo 5 do capítulo 2 tem as minhas regras práticas para quando uma lista merece seu próprio objeto.)

A família do texto

Ensino texto como dois tipos, e a linha entre eles é de 255 caracteres.

Até 255: armazenado com o registro. O Texto (Text) guarda até 255 caracteres, e você pode usá-lo quase em qualquer lugar: em fórmulas, filtros, relatórios, visualizações de lista, como campo único ou ID externo, e ele pode ser indexado. A Área de texto (Text Area) também guarda 255, em linhas separadas, como uma nota curta.

Acima de 255: armazenado por referência. A Área de texto longo (Text Area (Long)) guarda até 131.072 caracteres, e a Área de texto rich (Text Area (Rich)) guarda o mesmo, com formatação, links e imagens. Penso nelas como guardadas de lado, com o registro segurando um ponteiro, e elas se comportam assim: sem índice, então você não consegue torná-las únicas nem ID externo; não consegue filtrar por elas numa cláusula WHERE do SOQL (SOQL WHERE (opens in a new tab), em inglês); fórmulas não conseguem usá-las (Formula Field Limits and Restrictions (opens in a new tab), em inglês); e os relatórios mostram só os primeiros 254 caracteres de uma personalizada, com os filtros de relatório buscando só nos primeiros 255, mais ou menos (Filter Restrictions for Text Area (Long) Fields (opens in a new tab), em inglês). Imagens enviadas para um campo de texto rich podem ter até 1 MB cada, e contam no armazenamento de arquivos, enquanto o texto conta no armazenamento de dados (Rich Text Area Field Considerations (opens in a new tab), em inglês). Então, se alguém precisa buscar, ordenar, comparar ou fazer relatório pelo valor, mantenha-o abaixo de 255 e mantenha-o como campo de Texto.

O Texto criptografado (Text (Encrypted)) armazena até 175 caracteres em forma criptografada, usando a Classic Encryption. Se a sua org usa Shield Platform Encryption, você criptografa um campo de Texto comum, e muitos outros tipos também podem ser criptografados desse jeito.

Dê uma descrição a cada campo

Meu padrão: todo campo ganha uma descrição. Acredito nisso há muito tempo, e na era da IA isso importa mais do que nunca: toda ferramenta e todo agente de IA que lê a sua org lê as descrições para entender o que um campo significa. Uma descrição vazia é um chute esperando para acontecer. O que Customer_Status__c significa? Quem é o dono? De onde vem? Os usuários podem editá-lo, ou o ERP vai sobrescrevê-lo hoje à noite? Daqui a seis meses eu não vou lembrar, e daqui a três anos o administrador que mantém a org não vai saber, a menos que tenhamos contado. O rótulo não é documentação, e o nome de API também não.

Em objetos muito compartilhados (Conta, Contato, Oportunidade) também uso prefixos de nomenclatura para campos especializados, para que sua origem e seu propósito apareçam no próprio nome: tudo o que pertence ao ERP começa com o mesmo prefixo, por exemplo. Não estou atrás de nomes de API de doze palavras. Quero que o modelo se explique sozinho.

Classifique o que importa: os campos de taxonomia

O Salesforce dá a cada campo um conjunto de metadados de classificação. Eu os chamo de campos de taxonomia. Você pode registrar o proprietário dos dados (Data Owner); o uso do campo (Field Usage: Active, DeprecateCandidate, Hidden); o nível de sensibilidade dos dados (Data Sensitivity Level: Public, Internal, Confidential, Restricted, MissionCritical); e a categorização de conformidade (Compliance Categorization): PII, HIPAA, GDPR, PCI, CCPA e outras. Eles funcionam tanto em campos padrão quanto em personalizados (Data Classification Metadata Fields (opens in a new tab), em inglês).

Para que se dar ao trabalho? Porque os processos conseguem lê-los. Marque um campo como GDPR e um processo consegue encontrar todos os campos GDPR de um registro e mascará-los ou removê-los. E quando a camada de confiança da Salesforce envia um prompt para um grande modelo de linguagem, ela pode usar exatamente essa classificação para mascarar campos sensíveis: troca o nome de um cliente, digamos “Maria Lopez”, por um marcador na saída, o modelo nunca vê o nome, e o nome é recolocado na resposta na volta (Einstein Trust Layer (opens in a new tab), em inglês).

Uma atualização. A Salesforce agora documenta que o mascaramento por padrão e por campo para LLMs fica desativado para agentes: o mascaramento pode tirar o contexto de que um agente precisa para responder (Data Masking Limitations in Agentforce (opens in a new tab), em inglês). A classificação continua guiando o mascaramento em outros recursos de IA generativa, mas não conte com ela para manter dados pessoais longe de um agente; essa é uma decisão de acesso e de design (capítulo 12).

Minha posição: a classificação é importante nos momentos-chave. Não a transforme em três semanas preenchendo cada caixinha porque a governança mandou. Use-a onde importa: dados pessoais, dados financeiros, dados regulados, e campos em que o negócio precisa de um dono nomeado. O ponto é que a sensibilidade deixa de ser conhecimento na cabeça de alguém e passa a fazer parte do campo.

Além do exame: o que a IA muda. A documentação ruim de campos costumava punir o próximo administrador. Agora ela engana toda ferramenta e todo agente de IA que lê o esquema: Flag2__c é sensível, tem autoridade, ainda é usado? A IA também cria campos mais rápido do que qualquer equipe, então nomes, descrições e classificação fazem parte da arquitetura, não da faxina.

Cada campo é um compromisso

Depois que um campo está lá fora coletando dados, tudo começa a se apoiar nele. As telas o mostram, os fluxos se ramificam por ele, as regras de validação o verificam, os relatórios agrupam por ele, as integrações o enviam e o leem, e agora as ferramentas de IA raciocinam sobre ele. Cada um deles faz suposições sobre o campo: o tipo, o tamanho, se ele fica em branco alguma vez, e o que os valores significam. Mude o campo depois e você terá de encontrar cada uma dessas suposições primeiro. Renomear um valor de lista de opções, encurtar um campo de texto ou transformar um campo de Texto em lista de opções parece uma mudança pequena, e pode quebrar uma integração no sistema de outra empresa. É por isso que um campo é um compromisso.

Click to enlarge

Não quero que você saia deste módulo com medo de criar campos. O Salesforce foi feito para ser estendido; use isso. Quero que a pergunta mude de “que tipo de campo devo escolher?” para “o que este dado significa, e com que comportamento estamos nos comprometendo?” Tipo, obrigatório, único, ID externo, lista de opções, fórmula, descrição, classificação: juntos, eles são a expressão física do modelo lógico do capítulo 2.

O que um arquiteto decide aqui

• O que o valor significa antes de escolher o tipo de campo, e se ele é um atributo, um identificador, um vocabulário controlado ou, na verdade, outra entidade.
• Se um valor é um cálculo atual que pode ser derivado ou um fato histórico que precisa ser armazenado.
• Qual sistema é dono de cada identificador, e se a unicidade dele é uma promessa real do negócio.
• Quando um valor obrigatório é de fato conhecido, e o que acontece com registros e integrações que não o têm.
• Que descrição, nomenclatura e classificação o campo precisa para que pessoas, processos e IA possam usá-lo com segurança.

Para saber mais

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Help, Einstein Trust Layer: Designed for Trust (opens in a new tab) e Data Masking Limitations in Agentforce (opens in a new tab) (em inglês), consultados em 2026-10-02.
• Salesforce Developers, Insert or Update (Upsert) a Record Using an External ID (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Help, Picklist Limitations (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Help, Formula Field Limits and Restrictions (opens in a new tab) (em inglês), consultado em 2026-10-02.
• Salesforce Developers, Date Formats and Date Literals (opens in a new tab) (em inglês), consultado em 2026-10-02.