Os campos também são arquitetura

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

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

Criar um campo leva mais ou menos um minuto. Novo campo, escolha um tipo, dê-lhe um nome, Seguinte, Seguinte, Guardar. É 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 verificação que ninguém elimina porque ninguém sabe que integração ainda a usa. Criar o campo levou um minuto. Conviver com ele leva anos. Por isso a ideia deste módulo é simples: um campo é uma decisão de arquitetura. Nem sempre uma grande, mas cada campo codifica algo sobre o significado, o comportamento, a identificação ou a qualidade dos dados e, tal como os objetos, os campos são fáceis de acrescentar e surpreendentemente difíceis de tirar.

O que significa realmente este dado?

No capítulo 2 demos atributos às nossas entidades: uma Entrega tem uma janela agendada, um Camião tem um número de quadro (VIN). Agora implementamo-los, e é aqui que as pessoas saltam diretamente 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? Escrito por uma pessoa, ou propriedade de outro sistema? Pode mudar? Tem de ser único? Pode faltar? Deveria sequer ser armazenado, ou calculado? Estas não são perguntas de Setup. São perguntas de arquitetura de dados, e o tipo de campo vem depois de lhes responder.

Um número nem sempre é um número

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

Um humano precisa de o identificar?

Cada objeto personalizado ganha um campo Nome, e a primeira decisão é texto ou numeração automática. Pergunto: um humano precisa de identificar esta coisa? As pessoas conhecem um Parceiro retalhista pelo nome e um camião pelo número de frota. Mas um manifesto que o sistema gera todas as noites? Ninguém devia estar a escrever «Manifesto 10-02 Número 3» só porque o Salesforce exigiu um Nome. Dê-lhe uma numeração automática. Só não confunda esse Nome gerado com a identificação do registo: a numeração automática ajuda os utilizadores, o ID do Salesforce identifica o registo, e a referência de manifesto do próprio Parceiro retalhista pode identificar a mesma coisa entre sistemas. Três trabalhos diferentes.

O ecrã de detalhes

Escolha um tipo, clique em Seguinte, e o Setup pede os detalhes. É neste ecrã que a maioria das decisões deste módulo é realmente tomada, quase sempre à pressa.

New Custom Field (Novo campo personalizado), passo 2: os detalhes (captura de ecrã, 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 vem. Help Text (Texto de ajuda) é para o utilizador no ecrã: o que escrever aqui. Preencha as duas. Depois vêm Required (Obrigatório), Unique (Único) e External ID (ID externo), e cada um deles merece a sua própria secção. Abaixo deles, Default Value (Valor predefinido) pode ser uma fórmula, para que um registo 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 campos chamada Obrigatório, e como vimos no capítulo 1, pode ser uma bomba-relógio. Tem um objeto há cinco anos e dois milhões de registos, e agora alguém decide que um campo novo tem sempre de ter valor. E os dois milhões de registos anteriores a ele? As integrações que não o enviam? A automação que cria o registo antes de o valor ser conhecido? O processo em que o valor só aparece três etapas depois?

«Obrigatório» soa a 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. Por isso não marque Obrigatório só porque alguém diz «queremos sempre isso». Pergunte quando é conhecido, quem o fornece, e o que acontece quando não é. Vamos pôr isto na escada completa de consistência no módulo 7.

Único também significa algo

Se marco um campo como único, estou a fazer uma afirmação sobre o negócio: não «normalmente não se repete», mas «dois registos nunca podem ter este valor». Isso é forte. E o ecrã obriga-o a decidir mais uma coisa: «ABC» e «abc» são o mesmo valor ou valores diferentes? Não distinguir maiúsculas de minúsculas é a predefinição mais segura para qualquer coisa que uma pessoa escreve. 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 colaborador é único, começo a perguntar: pode mudar, alguém pode sair e voltar, os 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 faz dele uma boa identificação.

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

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

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

Tipo de campo por tipo de campo

Agora, os tipos em si. Abra New Field (Novo campo) em qualquer objeto e o Setup mostra-lhe a lista inteira, agrupada da forma como a vou percorrer: os campos que o Salesforce calcula por si, os campos de relação e, depois, os tipos de dados.

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

Eis a lista inteira num relance, com a única coisa que gostaria que recordasse 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 registo
	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-detalhe
Relações	Pesquisa, mestre-detalhe, pesquisa externa (Lookup, Master-Detail, External Lookup)	Módulo 7
Dados	Caixa de verificação (Checkbox)	Verdadeiro ou falso, com uma predefinição que escolhe; o nulo pode ainda assim aparecer em fluxos
	Número, percentagem, 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 guardar: 80, 40 e 255 caracteres
	Geolocalização, morada (Geolocation, Address)	Campos compostos que custam mais do que 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, encriptado (Text, Text Area, Long, Rich, Encrypted)	Até 255, no registo e indexável; acima disso, sem índice nem filtro

Os campos que o Salesforce calcula

A numeração automática (Auto Number) atribui o número seguinte de uma sequência a cada registo novo, num formato que define, como T-{000000}. Use-a 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 estão reservados para o prefixo ou o sufixo. Lembre-se apenas do capítulo 2: é um rótulo para pessoas, não a identificação do registo, 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 registo é lido, não quando é guardado, por isso não há nada armazenado que fique desatualizado. Escolhe o que a fórmula devolve: caixa de verificação, moeda, data, data/hora, número, percentagem, texto ou hora.

New Custom Field, fórmula: a escolher o tipo de retorno (captura de ecrã, 2026-10-12). Tamanho real

Depois 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-o a escrever a fórmula. Use-o, e depois leia o que ela escreveu. A fórmula é sua, não do assistente.

O editor de fórmulas, com o Formula Assistant (captura de ecrã, 2026-10-12). Tamanho real Uma fórmula pode ter até 3.900 caracteres, e não pode passar de 15.000 bytes quando guardada ou compilada; uma fórmula longa pode ser dividida em vários campos de fórmula que fazem referência uns aos outros. As áreas de texto longo, os campos encriptados e os 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 obtêm o mínimo ou o máximo dos registos de detalhe. Só funcionam numa relação mestre-detalhe, o que é um dos maiores motivos para escolher mestre-detalhe. Vamos voltar a eles, e aos seus limites, no módulo 7.

Armazenado ou derivado?

Precisamos sequer de armazenar este valor? Se tenho quantidade e preço unitário, alguém, ou alguma automação, precisa de manter um total? Talvez uma fórmula o deva derivar: uma fonte única para o cálculo, recalculada quando é lida, por isso mude a quantidade e a resposta acompanha. As fórmulas têm os seus próprios limites (tamanho ao guardar e tamanho apresentado; 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 mudar no próximo ano, a fatura do ano passado deveria de repente mostrar outro valor? Claro que não. Por isso a pergunta não é «o Salesforce consegue calcular isto?» É «isto é um cálculo atual ou um facto histórico?» Os factos históricos são armazenados.

Os campos de relação

As relações de pesquisa (Lookup), mestre-detalhe (Master-Detail) e pesquisa externa (External Lookup) também são campos, e é nelas que as linhas do seu modelo se tornam realidade. A pesquisa é a ligação solta; a mestre-detalhe amarra a vida, a propriedade e a segurança do filho ao pai; a pesquisa externa chega a um objeto externo do módulo 4, fazendo a correspondência pelo ID externo dele. Escolher entre elas é uma decisão grande o suficiente para merecer um módulo próprio.

Caixa de verificação

Uma caixa de verificação (Checkbox) é o campo mais simples que existe: verdadeiro ou falso, marcada ou desmarcada. É perfeita para um facto de sim ou não sobre o registo: Está ativo, Instalação necessária, Recebido com assinatura. Quando cria uma, o Salesforce obriga-o a escolher o valor predefinido, marcada ou desmarcada, e essa é uma decisão a sério: é com ele que todos os registos novos começam, incluindo os registos que uma integração cria sem enviar o campo. Os relatórios e as vistas de lista filtram-na como True e False; as ferramentas de importação e a exportação semanal mostram-na como 1 e 0.

Uma armadilha a conhecer. O campo no registo tem dois valores, mas a automação à volta dele pode ter um terceiro. Num fluxo, uma variável de caixa de verificação que nunca foi definida é nula, não falsa, e guardá-la num registo 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 uma predefinição sensata, e faça com que os seus fluxos e o seu código tratem o nulo de propósito.

Número, percentagem e moeda

O Número (Number) armazena um número real e descarta quaisquer zeros à esquerda, e é exatamente por isso que um número de frota como 001247 não é um Número. O Salesforce arredonda os campos de número a partir da metade, para longe do zero: 12,345 passa a 12,35, e −12,345 passa a −12,35. E nos campos de intercalação (merge fields), arredonda conforme as definições regionais do utilizador, não conforme as casas decimais que definiu no campo.

A Percentagem (Percent) armazena um decimal e mostra uma percentagem: introduza 0,10 e 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 transporta o código da moeda e pode usar taxas de câmbio; com a gestão avançada 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 à volta delas (produtos, calendários, divisões e os respetivos relatórios) usam taxas datadas; os campos de moeda noutros objetos mantêm a taxa estática única. Cuidado com o arredondamento: sem casas decimais, o Salesforce simplesmente trunca (23,5 passa a 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 expira numa data. Uma Data/hora (Date/Time) é um momento: a entrega chegou às 9h42 dessa manhã. Uma Hora (Time) é uma hora do dia, sem data nenhuma: a loja abre às 7h00, todos os dias.

A armadilha é o momento. O Salesforce armazena os valores de data/hora em GMT (UTC). A hora que um utilizador escreve é lida no fuso horário dele, convertida e armazenada; quando alguém a lê, é convertida de novo para o fuso horário de quem lê. Na maior parte do tempo, é exatamente o que quer. Mas eis o exemplo que dou nas aulas: uma coordenadora em Los Angeles regista uma entrega tarde no domingo à noite, às 22h, hora do Pacífico. Por baixo, o Salesforce armazenou segunda de manhã, 5h GMT. Um relatório agrupado por dia noutro fuso horário, ou uma integração a ler o valor bruto, pode pôr essa entrega de domingo na segunda. «O dia em que aconteceu» depende do relógio que consulta. Esteja atento aos fusos horários dos utilizadores, e decida a qual deles o negócio se refere.

E cuidado ao compará-los. Por baixo, uma data/hora é um número grande: o Apex lê-a 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. Por isso, perguntar se duas datas/horas são iguais (==) quase nunca faz o que quer: 9h42min00 e 9h42min01 não são iguais, e «segunda-feira» e um momento qualquer de segunda também não. Em vez disso, peça um intervalo: a partir do início (>=) e até ao fim (<=). «Todas as entregas de segunda» são todas as entregas >= segunda 00:00 e <= segunda 23:59:59, no fuso horário a que decidiu que o negócio se refere.

E uma curiosidade: o Salesforce não consegue armazenar uma data qualquer. As datas válidas vão de 1 de janeiro de 1700 até 31 de dezembro de 4000, e o Salesforce indica 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, por isso, para um utilizador na hora do Pacífico, o primeiro valor válido é às 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 precisa de um marcador num futuro distante, tem de estar no ano 4000 ou antes.

Email, telefone e URL

Estes são os campos formatados, e fazem mais do que guardar caracteres. O Email guarda até 80 caracteres e tem o formato verificado; nos contactos e leads, clicar nele começa um e-mail para esse endereço. O Telefone (Phone) guarda até 40 caracteres, é formatado como número de telefone e passa a clicar para ligar quando a org tem um sistema telefónico ligado. A URL guarda até 255 caracteres e abre como link. É a plataforma a dar-lhe 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 corresponde ao formato do campo, como um endereço de e-mail mal formado, falha a validação, e o registo inteiro é rejeitado, não só esse campo. Por isso, quando os dados do sistema de origem estão desarrumados, limpe-os antes de chegarem, ou planeie para os registos que não vão carregar.

Geolocalização e morada

A Geolocalização (Geolocation) guarda uma latitude e uma longitude. Por baixo, um campo chamado Location__c são na verdade dois valores que pode ler e definir separadamente, Location__Latitude__s e Location__Longitude__s. E pode fazer consultas por ele: as funções DISTANCE e GEOLOCATION do SOQL encontram registos dentro de um raio, ou ordenam-nos pela distância. «Todas as entregas abertas num raio de 25 milhas deste camiã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). A Morada (Address) guarda uma morada inteira, rua, cidade, estado ou província, código postal e país, e os utilizadores podem pesquisar uma morada e ter as partes preenchidas.

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

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

Uma lista de opções (Picklist) controla o que os utilizadores podem introduzir: um valor de uma lista que define. Estado? Lista de opções, provavelmente. Mas os valores são metadados, e um administrador tem de os adicionar ou alterar. Por isso continuo a perguntar quem é o dono dos valores, com que frequência mudam, se vários objetos precisam da mesma lista, se os valores transportam informação própria, e se outro sistema é dono do vocabulário.

Onde vivem os valores 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 defeito. Mas quando o mesmo conjunto de valores começa a aparecer em vários sítios, uma Região na conta, na entrega e no armazém, promova-o a conjunto de valores global antes que as cópias se afastem umas das outras. 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 porque é que isso importa: o conjunto de valores «is restricted so users can’t add unapproved values through the API» (é restrito para que os utilizadores não possam adicionar valores não aprovados através da API). Uma lista, um dono, e nenhuma integração a meter às escondidas 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 utilizador, uma importação ou uma integração que envie outra coisa qualquer recebe um erro, «bad value for restricted picklist field», e o registo não é guardado. Numa lista de opções não restrita, os utilizadores continuam a escolher da lista no ecrã, mas a API, as importações e a automação podem enviar qualquer valor, e o Salesforce guarda-o e adiciona-o 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». Os conjuntos de valores globais são sempre restritos. A minha predefiniçã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 ecrã, 2026-10-12). Tamanho real

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

Uma lista de opções também tem um valor a mais do que os que definiu: em branco. Um registo pode ficar sem nada selecionado, e isso apanha as pessoas desprevenidas. Numa fórmula ou regra de validação não consegue testar uma lista de opções só com ISBLANK; escreve ISBLANK(TEXT(Field__c)), ou ISPICKVAL(Field__c, "") (Trailblazer Community (opens in a new tab), em inglês). Por isso decida o que significa «sem valor» para cada lista de opções: é permitido, e o que significa quando acontece? Depois faça com que as suas fórmulas, regras de validação e filtros lidem 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. Depois descobrimos que cada um tem morada, gestor, horário, capacidade, região e camiõ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. 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 o 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 registo. O Texto (Text) guarda até 255 caracteres, e pode usá-lo quase em qualquer lado: em fórmulas, filtros, relatórios, vistas de lista, como campo único ou ID externo, e 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 à parte, com o registo a segurar um ponteiro, e comportam-se assim: sem índice, por isso não as consegue tornar ú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); as fórmulas não as conseguem usar (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 a pesquisar só nos primeiros 255, mais ou menos (Filter Restrictions for Text Area (Long) Fields (opens in a new tab), em inglês). As imagens carregadas para um campo de texto rich podem ter até 1 MB cada, e contam no armazenamento de ficheiros, enquanto o texto conta no armazenamento de dados (Rich Text Area Field Considerations (opens in a new tab), em inglês). Por isso, se alguém precisa de pesquisar, ordenar, comparar ou fazer relatórios pelo valor, mantenha-o abaixo de 255 e mantenha-o como campo de Texto.

O Texto encriptado (Text (Encrypted)) armazena até 175 caracteres em forma encriptada, usando a Classic Encryption. Se a sua org usa a Shield Platform Encryption, encripta antes um campo de Texto comum, e muitos outros tipos também podem ser encriptados dessa forma.

Dê uma descrição a cada campo

O meu padrão: cada campo ganha uma descrição. Acredito nisto há muito tempo, e na era da IA importa mais do que nunca: todas as ferramentas e todos os agentes de IA que leem a sua org leem as descrições para entender o que um campo significa. Uma descrição vazia é um palpite à espera de acontecer. O que significa Customer_Status__c? Quem é o dono? De onde vem? Os utilizadores podem editá-lo, ou o ERP vai sobrescrevê-lo esta noite? Daqui a seis meses não me vou lembrar, e daqui a três anos o administrador que mantém a org não vai saber, a menos que lho tenhamos dito. O rótulo não é documentação, e o nome de API também não.

Em objetos muito partilhados (Conta, Contacto, Oportunidade) também uso prefixos de nomenclatura para campos especializados, para que a sua origem e o 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 ando 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. Chamo-lhes campos de taxonomia. Pode registar o proprietário dos dados (Data Owner); a utilização 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. Funcionam tanto em campos padrão como em personalizados (Data Classification Metadata Fields (opens in a new tab), em inglês).

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

Uma atualização. A Salesforce documenta agora 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 a orientar o mascaramento noutras funcionalidades 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).

A minha posição: a classificação é importante nos momentos-chave. Não a transforme em três semanas a preencher cada caixinha porque a governação 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 má documentação de campos costumava castigar o administrador seguinte. Agora engana todas as ferramentas e todos os agentes de IA que leem o esquema: Flag2__c é sensível, tem autoridade, ainda é usado? A IA também cria campos mais depressa do que qualquer equipa, por isso nomes, descrições e classificação fazem parte da arquitetura, não das limpezas.

Cada campo é um compromisso

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

Click to enlarge

Não quero que 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 significa este dado, e com que comportamento nos estamos a comprometer?» Tipo, obrigatório, único, ID externo, lista de opções, fórmula, descrição, classificação: juntos, 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 é 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 facto histórico que tem de ser armazenado.
• Que sistema é dono de cada identificador, e se a sua unicidade é uma promessa real do negócio.
• Quando um valor obrigatório é de facto conhecido, e o que acontece aos registos 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 o possam usar 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.