Objetos personalizados

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)

In a truck body shop, a custom white box body hangs on chains above a standard truck chassis, already fitted with its doors, lights and mud flaps. — Imagem gerada com IA

Módulo 3 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo se sustenta sozinho. Anterior: Olhe para a nave-mãe: os modelos de dados padrão · Próximo: Onde esses dados vivem?

A pergunta que este módulo responde: Quando o Salesforce não tem, o que você ganha de fato ao construir seu próprio objeto?

No último módulo vimos o que a Salesforce já construiu. Às vezes ela não tem o que você precisa. A Steve Trucking opera caminhões, e não existe um objeto padrão Truck (Caminhão). Então você constrói um: um objeto personalizado.

Eis o que eu quero que você veja neste módulo. Um objeto personalizado é criado em metadados, como tudo no módulo 1, e no momento em que ele existe já vem com um conjunto de funcionalidades padrão. Não é uma tabela em branco. E a tela que você preenche para criá-lo está fazendo perguntas de arquitetura, quer você perceba ou não.

A tela New Custom Object

Vá em Setup → Object Manager → Create → Custom Object (Gerenciador de objetos → Criar → Objeto personalizado) e você recebe um formulário comprido. A maioria das pessoas preenche as duas primeiras caixas e clica em Save (Salvar). Vamos desacelerar e lê-lo.

Label e Plural Label (Rótulo e Rótulo no plural). “Truck” e “Trucks”. É o que os usuários veem, nas guias, nos layouts de página e nos relatórios. Você pode mudá-los depois sem muita dor.

Object Name (Nome do objeto). Este é diferente: é o nome de API, o nome que o código, as integrações, os relatórios e agora os agentes usam. Digite “Truck” e o Salesforce o transforma em Truck__c. Mudá-lo depois significa encontrar tudo o que se refere a ele, o que é de novo o Teste de Reversibilidade do capítulo 1. Acerte este de primeira.

Description (Descrição). Preencha. Toda vez. No módulo 1 eu disse que metadados não são mais decoração: o próximo administrador lê isso, e também toda ferramenta de IA que tenta entender sua org. Um objeto personalizado com a descrição vazia é uma caixa sem etiqueta.

Record Name (Nome do registro). Todo objeto personalizado tem um campo Nome, e é aqui que você decide o que ele é. Um nome do tipo Text (Texto), como “Truck 117”, ou uma Auto Number (numeração automática), como T-000184, que o Salesforce preenche para você. Leia o aviso nessa tela: se você pretende inserir um alto volume de registros pela API, o Salesforce diz para usar Text. É a plataforma dizendo algo sobre escala antes de você ter criado um único registro.

A seção Record Name da tela New Custom Object: a caixa Record Name, um Data Type Text, e o aviso para usar o tipo de dado Text se você pretende inserir um alto volume de registros pela API

Setup do Salesforce, New Custom Object: a seção Record Name, com seu aviso (captura de tela, 2026-10-12). Tamanho real

Optional Features (Recursos opcionais). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Desligados por padrão. Cada um é uma capacidade que você está ligando para este objeto; decida de propósito.

Object Classification (Classificação do objeto). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, todos ligados por padrão. A tela diz com todas as letras: com eles ligados, o objeto é um objeto Enterprise Application; com eles desligados, é um objeto Light Application. Esses nomes batem com as licenças de assinatura de aplicativos da Salesforce: um Lightning Platform Light App não tem compartilhamento no nível do registro e não pode usar a Bulk API nem a Streaming API, e um Enterprise App pode. Meu conselho: deixe-os ligados, a menos que você saiba exatamente por que não. Desligue o acesso à Bulk API num objeto que você depois vai carregar em volume, e você vai descobrir por que isso importava.

Deployment Status e Search (Status de implantação e Pesquisa). “In Development” esconde o objeto dos usuários enquanto você o constrói; “Deployed” o coloca no ar. E Allow Search (Permitir pesquisa) vem desligado por padrão, então os usuários não vão encontrar esses registros na pesquisa global até você ligá-lo. Esse pega as pessoas toda vez.

Os padrões: as três configurações de API ligadas, Deployed, e Allow Search desligado (captura de tela, 2026-10-12). Tamanho real

Clique em Save, e o Gerenciador de objetos mostra o objeto: nome de API Truck__c, uma marca em Custom, os rótulos, o status de implantação. Mas olhe a coluna da esquerda: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Essa lista é o módulo 1 tornado visível. Um objeto não é só armazenamento; é o lugar de onde todo esse comportamento fica pendurado.

O Gerenciador de objetos mostrando o objeto Truck: API Name Truck__c, Custom marcado, os rótulos no singular e no plural, e a lista da esquerda, de Fields & Relationships a Validation Rules

Gerenciador de objetos, Truck: o nome de API Truck__c, Custom, e tudo o que fica pendurado num objeto (captura de tela, 2026-10-12). Tamanho real

Os campos que você não criou

Abra Fields & Relationships num objeto personalizado recém-criado, e ele já tem campos. Todo objeto personalizado ganha um conjunto padrão:

Name (Nome), o nome do registro que você acabou de escolher, usado em layouts de página, listas relacionadas, pesquisas e resultados de busca.
Owner (Proprietário), o usuário ou a fila dona do registro.
Created By e Last Modified By (Criado por e Modificado pela última vez por), os usuários que o criaram e o alteraram por último.
Currency (Moeda), se a multimoeda estiver ligada, e Division (Divisão), se sua org usa divisões.

E por baixo, o ID de registro do módulo 1, e as datas de criação e de modificação. Exporte alguns registros com o Data Loader e você vai ver todos eles.

Um deles pode desaparecer. Faça do seu objeto personalizado o lado detalhe de um relacionamento mestre-detalhes, e o campo Owner some: a propriedade passa a vir do registro mestre. Isso é mais sério do que parece, e vamos voltar a isso nos módulos 7 e 8.

Prefixos e sufixos: o que você está vendo

No último módulo eu disse que objetos padrão não têm prefixo nem sufixo. Todo o resto tem, e quando você consegue lê-los, uma lista de campos diz exatamente o que você está vendo.

Como aparece	O que é
`Account`, `Case`	Um objeto ou campo padrão: sem prefixo, sem sufixo
`Truck__c`	Um objeto personalizado, ou um campo personalizado, como `Unit_Number__c`
`abc__Inspection__c`	Um objeto personalizado de um pacote gerenciado: `abc` é o namespace do fornecedor
`Delivery_History__b`	Um big object (módulo 4)
`Shipment__x`	Um objeto externo: os dados vivem em outro sistema (módulo 4)
`Allergies__pc`	Um campo de contato personalizado numa conta pessoal (módulo 2)
`Truck__r`	O relacionamento por trás de uma pesquisa personalizada, quando você o segue numa consulta

Algumas coisas para notar.

Até aqui, isso é uma lista. Eis como eu ensino: em camadas. Existem três tipos de objeto, padrão, personalizado e de pacote gerenciado, e cada um deles pode ter os mesmos tipos de campo: os campos padrão com que veio, e os campos personalizados que alguém acrescentou.

Objetos padrão. Account não tem prefixo nem sufixo, e seus campos padrão também não: Name, Industry, OwnerId. Você pode acrescentar campos personalizados à maioria dos objetos padrão, e todo campo que você acrescenta termina em __c: Region__c (Custom Fields (opens in a new tab), em inglês). É esse sufixo que protege você. A Salesforce acrescenta novos campos padrão a Account nas suas releases, e como os seus sempre terminam em __c e os dela nunca, um campo padrão futuro nunca vai colidir com um campo que você já tem.

Objetos personalizados. O seu próprio objeto termina em __c, Truck__c (Custom Objects (opens in a new tab), em inglês), e os campos personalizados que você coloca nele também: Unit_Number__c. Mas os campos com que ele nasceu, os da seção anterior, são campos padrão: Name, OwnerId, CreatedDate, sem sufixo. Então, mesmo no seu próprio objeto, o sufixo diz quem fez cada campo.

Objetos de pacote gerenciado. Quando você instala um pacote gerenciado da AppExchange, os objetos e campos dele vêm com o prefixo de namespace do fornecedor: abc__Inspection__c, e campos como abc__Result__c. Esse prefixo é exclusivo do fornecedor, e não muda (Namespace Prefix (opens in a new tab), em inglês). Nas palavras da própria Salesforce, o prefixo é acrescentado a cada componente para torná-lo único: name__c vira prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab), em inglês). Assim, dois fornecedores podem entregar um objeto chamado Invoice__c e nunca colidir um com o outro, nem com você. Os objetos do pacote continuam tendo seus campos padrão, Name e OwnerId, sem prefixo. Um pacote também pode acrescentar seus próprios campos com prefixo a objetos padrão, como abc__Score__c em Account. E você pode acrescentar seus próprios campos personalizados aos objetos de um pacote: Depot__c em abc__Inspection__c leva o seu sufixo __c, mas nunca o prefixo do fornecedor, porque quem o fez foi você, não ele (Known Issue: unmanaged custom field on a managed package object (opens in a new tab), em inglês).

Click to enlarge

Leia qualquer nome de API e você sabe quem o fez. Sem sufixo: a Salesforce. __c sem prefixo: a sua org. abc__ na frente: o fornecedor. Isso importa toda vez que você planeja uma mudança. O que é seu, você pode mudar. O que é da Salesforce, você configura e estende. O que é do fornecedor fica, em boa parte, travado: algumas coisas, como layouts de página e texto de ajuda, você pode editar, mas a maior parte do pacote, e todo nome de API, pertence ao fornecedor, e as atualizações dele trazem as mudanças dele (Editable Properties After Package Promotion or Installation (opens in a new tab), em inglês).

Pacotes não gerenciados não têm prefixo. Instale um pacote não gerenciado, e os objetos dele chegam à sua org como se você mesmo os tivesse construído, sem prefixo. Se ele trouxer um Truck__c e você já tiver um, você tem uma colisão de nomes. Verifique antes de instalar.

Construa só o que o Salesforce não tem

Criar um objeto personalizado é fácil; é exatamente por isso que acho que criamos objetos demais. A tela New Custom Object vai alegremente criar um Customer__c para você numa org que já tem Conta. Então, antes de clicar, faça a pergunta do último módulo: a nave-mãe já tem isso? Se tem, use. Se não tem, construa, e preencha a tela inteira como um arquiteto.

O próximo módulo faz uma pergunta ainda anterior: esses dados deveriam estar no Salesforce, para começo de conversa?

O que um arquiteto decide aqui

Se o Salesforce já tem um objeto padrão para isso, antes de construir um personalizado.
O nome de API, escolhido uma vez, e uma descrição escrita para pessoas e máquinas.
O nome do registro: texto ou numeração automática, com o volume esperado em mente.
Quais recursos opcionais, acesso por API e pesquisa ligar, de propósito.
O que os sufixos numa org dizem: personalizado, gerenciado, big object, externo, conta pessoal.
Se um pacote que você está prestes a instalar pode colidir com o que você construiu.

Para saber mais

Custom Objects (opens in a new tab) e Custom Fields (opens in a new tab), Object Reference (em inglês, consultado em 2026-10-13): “os nomes de objetos personalizados incluem um sufixo de dois sublinhados seguidos de um ‘c’ minúsculo”; o mesmo vale para campos personalizados; e a tabela dos objetos padrão que aceitam campos personalizados.
AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (em inglês, consultado em 2026-10-13): um prefixo de namespace torna único cada componente empacotado; “name__c vira prefix__name__c”.
Namespace Prefix (opens in a new tab), Apex Developer Guide (em inglês, consultado em 2026-10-13): os prefixos de namespace mantêm os nomes de objetos e campos dos pacotes gerenciados separados dos de outras orgs.
Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (em inglês, consultado em 2026-10-13): quais propriedades dos componentes de um pacote o desenvolvedor, o assinante, ambos ou nenhum dos dois podem editar.
Custom Object Standard Fields (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): os campos padrão que todo objeto personalizado ganha (Name, Owner, Created By, Last Modified By, Currency, Division), e por que o Owner é removido no lado detalhe de um relacionamento mestre-detalhes.
Standard User Licenses (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): um Lightning Platform Light App “não pode usar a Bulk API nem a Streaming API”; um Enterprise App “oferece compartilhamento no nível do registro e pode usar a Bulk API e a Streaming API”.