Objetos personalizados
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)

Módulo 3 de 10 do capítulo Arquitetura de dados Salesforce, capítulo 3 do curso Data Architect. Cada módulo sustenta-se sozinho. Anterior: Olhe para a nave-mãe: os modelos de dados padrão · Próximo: Onde vivem estes dados?
A pergunta a que este módulo responde: Quando o Salesforce não o tem, o que ganha de facto ao construir o seu próprio objeto?
No último módulo vimos o que a Salesforce já construiu. Às vezes não tem aquilo de que precisa. A Steve Trucking opera camiões, e não existe um objeto padrão Truck (Camião). Então constrói um: um objeto personalizado.
Eis o que quero que veja neste módulo. Um objeto personalizado é criado em metadados, como tudo no módulo 1, e no momento em que existe já vem com um conjunto de funcionalidades padrão. Não é uma tabela em branco. E o ecrã que preenche para o criar está a fazer-lhe perguntas de arquitetura, quer repare nisso quer não.
O ecrã New Custom Object
Seção intitulada “O ecrã New Custom Object ”Vá a Setup → Object Manager → Create → Custom Object (Gestor de objetos → Criar → Objeto personalizado) e recebe um formulário comprido. A maioria das pessoas preenche as duas primeiras caixas e clica em Save (Guardar). Vamos abrandar e lê-lo.
Label e Plural Label (Rótulo e Rótulo no plural). «Truck» e «Trucks». É o que os utilizadores veem, nos separadores, nos layouts de página e nos relatórios. Pode mudá-los depois sem grande 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. Escreva «Truck» e o Salesforce transforma-o 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 neste à primeira.
Description (Descrição). Preencha-a. Sempre. No módulo 1 disse que os metadados já não são decoração: o próximo administrador lê isto, e também todas as ferramentas de IA que tentam entender a sua org. Um objeto personalizado com a descrição vazia é uma caixa sem etiqueta.
Record Name (Nome do registo). Todos os objetos personalizados têm um campo Nome, e é aqui que 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 por si. Leia o aviso nesse ecrã: se pretende inserir um grande volume de registos através da API, o Salesforce diz para usar Text. É a plataforma a dizer-lhe algo sobre escala antes de ter criado um único registo.

Setup do Salesforce, New Custom Object: a secção Record Name, com o seu aviso (captura de ecrã, 2026-10-12). Tamanho real
Optional Features (Funcionalidades opcionais). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Desligadas por defeito. Cada uma é uma capacidade que está a ligar para este objeto; decida de propósito.
Object Classification (Classificação do objeto). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, todas ligadas por defeito. O ecrã di-lo com todas as letras: com elas ligadas, o objeto é um objeto Enterprise Application; com elas desligadas, é um objeto Light Application. Esses nomes correspondem às licenças de subscrição de aplicações da Salesforce: uma Lightning Platform Light App não tem partilha ao nível do registo e não pode usar a Bulk API nem a Streaming API, e uma Enterprise App pode. O meu conselho: deixe-as ligadas, a menos que saiba exatamente porque não. Desligue o acesso à Bulk API num objeto que mais tarde vai carregar em volume, e vai descobrir porque é que isso importava.
Deployment Status e Search (Estado de implementação e Pesquisa). «In Development» esconde o objeto dos utilizadores enquanto o constrói; «Deployed» põe-no a funcionar. E Allow Search (Permitir pesquisa) vem desligado por defeito, por isso os utilizadores não vão encontrar estes registos na pesquisa global até o ligar. Este apanha as pessoas sempre.

As predefinições: as três definições de API ligadas, Deployed, e Allow Search desligado (captura de ecrã, 2026-10-12). Tamanho real
Clique em Save, e o Gestor de objetos mostra-lhe o objeto: nome de API Truck__c, um visto em Custom, os rótulos, o estado de implementação. Mas olhe para 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.

Gestor de objetos, Truck: o nome de API Truck__c, Custom, e tudo o que fica pendurado num objeto (captura de ecrã, 2026-10-12). Tamanho real
Os campos que não criou
Seção intitulada “Os campos que não criou ”Abra Fields & Relationships num objeto personalizado acabado de criar, e ele já tem campos. Todos os objetos personalizados ganham um conjunto padrão:
- Name (Nome), o nome do registo que acabou de escolher, usado em layouts de página, listas relacionadas, pesquisas e resultados de pesquisa.
- Owner (Proprietário), o utilizador ou a fila dona do registo.
- Created By e Last Modified By (Criado por e Modificado pela última vez por), os utilizadores que o criaram e o alteraram por último.
- Currency (Moeda), se a multimoeda estiver ligada, e Division (Divisão), se a sua org usa divisões.
E por baixo, o ID de registo do módulo 1, e as datas de criação e de modificação. Exporte alguns registos com o Data Loader e vai vê-los todos.
Um deles pode desaparecer. Faça do seu objeto personalizado o lado detalhe de uma relação mestre-detalhe, e o campo Owner desaparece: a propriedade passa a vir do registo mestre. Isso é mais sério do que parece, e vamos voltar a isso nos módulos 7 e 8.
Prefixos e sufixos: o que está a ver
Seção intitulada “Prefixos e sufixos: o que está a ver ”No último módulo disse que os objetos padrão não têm prefixo nem sufixo. Tudo o resto tem, e quando os consegue ler, uma lista de campos diz-lhe exatamente o que está a ver.
| 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 gerido: abc é o namespace do fornecedor |
Delivery_History__b | Um big object (módulo 4) |
Shipment__x | Um objeto externo: os dados vivem noutro sistema (módulo 4) |
Allergies__pc | Um campo de contacto personalizado numa conta pessoal (módulo 2) |
Truck__r | A relação por trás de uma pesquisa personalizada, quando a segue numa consulta |
Algumas coisas a reparar.
Até aqui, isto é uma lista. Eis como o ensino: em camadas. Existem três tipos de objeto, padrão, personalizado e de pacote gerido, 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 os seus campos padrão também não: Name, Industry, OwnerId. Pode acrescentar campos personalizados à maioria dos objetos padrão, e cada campo que acrescenta termina em __c: Region__c (Custom Fields (opens in a new tab), em inglês). É esse sufixo que o protege. A Salesforce acrescenta novos campos padrão a Account nas suas versões, e como os seus terminam sempre em __c e os dela nunca, um campo padrão futuro nunca vai colidir com um campo que 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 lhe coloca também: Unit_Number__c. Mas os campos com que nasceu, os da secção anterior, são campos padrão: Name, OwnerId, CreatedDate, sem sufixo. Por isso, mesmo no seu próprio objeto, o sufixo diz-lhe quem fez cada campo.
Objetos de pacote gerido. Quando instala um pacote gerido 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 o tornar único: name__c passa a 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 consigo. Os objetos do pacote continuam a ter os seus campos padrão, Name e OwnerId, sem prefixo. Um pacote também pode acrescentar os seus próprios campos com prefixo a objetos padrão, como abc__Score__c em Account. E pode acrescentar os 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 o leitor, não ele (Known Issue: unmanaged custom field on a managed package object (opens in a new tab), em inglês).
Leia qualquer nome de API e sabe quem o fez. Sem sufixo: a Salesforce. __c sem prefixo: a sua org. abc__ à frente: o fornecedor. Isso importa sempre que planeia uma mudança. O que é seu, pode mudar. O que é da Salesforce, configura e estende. O que é do fornecedor fica, em boa parte, bloqueado: algumas coisas, como os layouts de página e o texto de ajuda, pode editar, mas a maior parte do pacote, e todos os nomes de API, pertencem 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).
Os pacotes não geridos não têm prefixo. Instale um pacote não gerido, e os objetos dele chegam à sua org como se os tivesse construído, sem prefixo. Se ele trouxer um Truck__c e já tiver um, tem uma colisão de nomes. Verifique antes de instalar.
Construa só o que o Salesforce não tem
Seção intitulada “Construa só o que o Salesforce não tem ”Criar um objeto personalizado é fácil; é exatamente por isso que acho que criamos objetos a mais. O ecrã New Custom Object cria-lhe alegremente um Customer__c numa org que já tem Conta. Por isso, antes de clicar, faça a pergunta do último módulo: a nave-mãe já tem isto? Se tem, use-o. Se não tem, construa-o, e preencha o ecrã inteiro como um arquiteto.
O próximo módulo faz uma pergunta ainda anterior: estes dados deviam estar no Salesforce, à partida?
O que um arquiteto decide aqui
Seção intitulada “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 registo: texto ou numeração automática, com o volume esperado em mente.
- Que funcionalidades opcionais, acesso por API e pesquisa ligar, de propósito.
- O que os sufixos numa org lhe dizem: personalizado, gerido, big object, externo, conta pessoal.
- Se um pacote que está prestes a instalar pode colidir com o que construiu.
Para saber mais
Seção intitulada “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 os 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 passa a 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 geridos 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): que propriedades dos componentes de um pacote o programador, o subscritor, 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 todos os objetos personalizados ganham (Name, Owner, Created By, Last Modified By, Currency, Division), e porque é que o Owner é removido no lado detalhe de uma relação mestre-detalhe.
- Standard User Licenses (opens in a new tab), Ajuda do Salesforce (em inglês, consultado em 2026-10-12): uma Lightning Platform Light App «não pode usar a Bulk API nem a Streaming API»; uma Enterprise App «oferece partilha ao nível do registo e pode usar a Bulk API e a Streaming API».
