Aangepaste objecten

Ook beschikbaar in 28 talen

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · 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. — Afbeelding gegenereerd met AI

Module 3 van 10 in het hoofdstuk Salesforce-data-architectuur, hoofdstuk 3 van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Kijk naar het moederschip: de standaard datamodellen · Volgende: Waar staan deze gegevens?

De vraag die deze module beantwoordt: Als Salesforce het niet heeft, wat krijg je dan eigenlijk als je je eigen object bouwt?

In de vorige module keken we naar wat Salesforce al gebouwd heeft. Soms heeft het niet wat je nodig hebt. Steve Trucking rijdt met vrachtwagens, en er is geen standaardobject Truck. Dus bouw je er een: een aangepast object.

Dit wil ik je in deze module laten zien. Een aangepast object wordt in metadata aangemaakt, net als al het andere uit module 1, en zodra het bestaat, komt het met een set standaardfunctionaliteit. Het is geen lege tabel. En het scherm dat je invult om het aan te maken, stelt je architectuurvragen, of je het nu merkt of niet.

Het scherm New Custom Object

Ga naar Setup → Object Manager → Create → Custom Object en je krijgt één lang formulier. De meeste mensen vullen de eerste twee vakjes in en klikken op Save. Laten we het rustig aan doen en het lezen.

Label en Plural Label (label en meervoudslabel). “Truck” en “Trucks”. Dit is wat gebruikers zien, in tabbladen, pagina-indelingen en rapporten. Je kunt ze later zonder veel pijn wijzigen.

Object Name (objectnaam). Deze is anders: het is de API-naam, de naam die code, integraties, rapporten en nu ook agents gebruiken. Typ “Truck” en Salesforce maakt er Truck__c van. Hem later wijzigen betekent alles vinden wat ernaar verwijst, en dat is weer de omkeerbaarheidstest uit hoofdstuk 1. Doe deze in één keer goed.

Description (omschrijving). Vul hem in. Elke keer. In module 1 zei ik dat metadata geen versiering meer is: de volgende admin leest dit, en elke AI-tool die je org probeert te begrijpen ook. Een aangepast object zonder omschrijving is een doos zonder etiket.

Record Name (recordnaam). Elk aangepast object heeft een veld Name, en hier beslis je wat dat is. Een Text-naam, zoals “Truck 117”, of een Auto Number (automatisch nummer), zoals T-000184, dat Salesforce voor je invult. Lees de waarschuwing op dat scherm: als je van plan bent een groot volume records via de API in te voegen, zegt Salesforce dat je Text moet gebruiken. Dat is het platform dat je iets over schaal vertelt voordat je ook maar één record hebt aangemaakt.

Het onderdeel Record Name van het scherm New Custom Object: het vak Record Name, een Data Type Text, en de waarschuwing om het gegevenstype Text te gebruiken als je van plan bent een groot volume records via de API in te voegen

Salesforce Setup, New Custom Object: het onderdeel Record Name, met zijn waarschuwing (screenshot, 2026-10-12). Volledige grootte

Optional Features (optionele functies). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups. Standaard uit. Elk ervan is een mogelijkheid die je voor dit object aanzet; beslis bewust.

Object Classification (objectclassificatie). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access, standaard allemaal aan. Het scherm zegt het gewoon: met deze aan is het object een Enterprise Application-object; met deze uit is het een Light Application-object. Die namen sluiten aan bij de app-abonnementslicenties van Salesforce: een Lightning Platform Light App heeft geen delen op recordniveau en kan de Bulk API en Streaming API niet gebruiken, en een Enterprise App kan dat wel. Mijn advies: laat ze aan, tenzij je precies weet waarom niet. Zet Bulk API-toegang uit op een object dat je later in grote volumes laadt, en je ontdekt vanzelf waarom het ertoe deed.

Deployment Status en Search (implementatiestatus en zoeken). “In Development” verbergt het object voor gebruikers terwijl je het bouwt; “Deployed” zet het live. En Allow Search staat standaard uit, dus gebruikers vinden deze records niet via globaal zoeken tot je het aanzet. Daar trappen mensen elke keer weer in.

De standaardinstellingen: de drie API-instellingen aan, Deployed, en Allow Search uit (screenshot, 2026-10-12). Volledige grootte

Klik op Save, en Object Manager toont je het object: API-naam Truck__c, een vinkje bij Custom, de labels, de implementatiestatus. Kijk wel even langs de linkerkant: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access. Die lijst is module 1, zichtbaar gemaakt. Een object is niet alleen opslag; het is de plek waar al dat gedrag aan hangt.

Object Manager met het object Truck: API Name Truck__c, Custom aangevinkt, enkelvoudige en meervoudige labels, en de lijst aan de linkerkant van Fields & Relationships tot Validation Rules

Object Manager, Truck: de API-naam Truck__c, Custom, en alles wat aan een object hangt (screenshot, 2026-10-12). Volledige grootte

De velden die je niet zelf hebt gemaakt

Open Fields & Relationships bij een gloednieuw aangepast object, en het heeft al velden. Elk aangepast object krijgt een standaardset:

Name, de recordnaam die je net koos, gebruikt in pagina-indelingen, gerelateerde lijsten, lookups en zoekresultaten.
Owner, de gebruiker of wachtrij die eigenaar is van het record.
Created By en Last Modified By, de gebruikers die het aanmaakten en het laatst wijzigden.
Currency, als meerdere valuta aan staan, en Division, als je org divisies gebruikt.

En daaronder de record-ID uit module 1, en de aanmaak- en wijzigingsdatums. Exporteer een paar records met Data Loader en je ziet ze allemaal.

Eén ervan kan verdwijnen. Maak je aangepaste object de detailkant van een hoofd-detailrelatie, en het veld Owner verdwijnt: het eigenaarschap komt dan van het hoofdrecord. Dat is belangrijker dan het klinkt, en we komen erop terug in module 7 en 8.

Voorvoegsels en achtervoegsels: waar je naar kijkt

In de vorige module zei ik dat standaardobjecten geen voorvoegsel en geen achtervoegsel hebben. Al het andere wel, en zodra je ze kunt lezen, vertelt een veldenlijst je precies waar je naar kijkt.

Hoe het eruitziet	Wat het is
`Account`, `Case`	Een standaardobject of -veld: geen voorvoegsel, geen achtervoegsel
`Truck__c`	Een aangepast object, of een aangepast veld, zoals `Unit_Number__c`
`abc__Inspection__c`	Een aangepast object uit een managed package: `abc` is de namespace van de leverancier
`Delivery_History__b`	Een big object (module 4)
`Shipment__x`	Een extern object: de data staat in een ander systeem (module 4)
`Allergies__pc`	Een aangepast contactveld op een persoonsaccount (module 2)
`Truck__r`	De relatie achter een aangepaste lookup, als je die in een query volgt

Een paar dingen om op te letten.

Tot nu toe is dat een lijst. Zo leer ik het: als lagen. Er zijn drie soorten objecten, standaard, aangepast en managed package, en op elk ervan kunnen dezelfde soorten velden staan: de standaardvelden waarmee het kwam, en de aangepaste velden die iemand heeft toegevoegd.

Standaardobjecten. Account heeft geen voorvoegsel en geen achtervoegsel, en de standaardvelden ook niet: Name, Industry, OwnerId. Je kunt aangepaste velden toevoegen aan de meeste standaardobjecten, en elk veld dat je toevoegt eindigt op __c: Region__c (Custom Fields (opens in a new tab), Engels). Dat achtervoegsel houdt je veilig. Salesforce voegt in zijn releases nieuwe standaardvelden toe aan Account, en omdat de jouwe altijd op __c eindigen en die van hen nooit, kan een toekomstig standaardveld nooit botsen met een veld dat je al hebt.

Aangepaste objecten. Je eigen object eindigt op __c, Truck__c (Custom Objects (opens in a new tab), Engels), en de aangepaste velden die je erop zet ook: Unit_Number__c. Maar de velden waarmee het geboren werd, die uit het vorige onderdeel, zijn standaardvelden: Name, OwnerId, CreatedDate, zonder achtervoegsel. Dus zelfs op je eigen object vertelt het achtervoegsel je wie elk veld heeft gemaakt.

Managed-packageobjecten. Als je een managed package uit AppExchange installeert, komen de objecten en velden ervan met het namespacevoorvoegsel van de leverancier: abc__Inspection__c, en velden als abc__Result__c. Dat voorvoegsel is uniek voor de leverancier, en het verandert niet (Namespace Prefix (opens in a new tab), Engels). In de woorden van Salesforce zelf wordt het voorvoegsel aan elk onderdeel toegevoegd om het uniek te maken: name__c wordt prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab), Engels). Zo kunnen twee leveranciers allebei een object Invoice__c leveren zonder ooit met elkaar te botsen, of met jou. De objecten van het package hebben nog steeds hun standaardvelden, Name en OwnerId, zonder voorvoegsel. Een package kan ook eigen velden met voorvoegsel aan standaardobjecten toevoegen, zoals abc__Score__c op Account. En je kunt je eigen aangepaste velden aan de objecten van een package toevoegen: Depot__c op abc__Inspection__c krijgt jouw achtervoegsel __c, maar nooit het voorvoegsel van de leverancier, want jij hebt het gemaakt, niet zij (Known Issue: unmanaged custom field on a managed package object (opens in a new tab), Engels).

Click to enlarge

Lees een willekeurige API-naam en je weet wie hem gemaakt heeft. Geen achtervoegsel: Salesforce. __c zonder voorvoegsel: jouw org. abc__ ervoor: de leverancier. Dat doet ertoe elke keer dat je een wijziging plant. Wat van jou is, kun je wijzigen. Wat van Salesforce is, configureer en breid je uit. Wat van de leverancier is, zit grotendeels op slot: een paar dingen, zoals pagina-indelingen en helptekst, mag je zelf bewerken, maar het grootste deel van het package, en elke API-naam, is van de leverancier, en hun upgrades brengen hun wijzigingen mee (Editable Properties After Package Promotion or Installation (opens in a new tab), Engels).

Unmanaged packages niet. Installeer een unmanaged package, en de objecten ervan landen in je org alsof je ze zelf had gebouwd, zonder voorvoegsel. Als het een Truck__c meebrengt en jij hebt er al een, heb je een naamconflict. Controleer het voordat je installeert.

Bouw alleen wat Salesforce niet heeft

Een aangepast object maken is makkelijk; precies daarom denk ik dat we er te veel van maken. Het scherm New Custom Object maakt met plezier een Customer__c voor je in een org die al Account heeft. Dus voordat je erop klikt, stel de vraag uit de vorige module: heeft het moederschip dit al? Zo ja, gebruik het. Zo nee, bouw het, en vul het hele scherm in als een architect.

De volgende module stelt een nog eerdere vraag: hoort deze data überhaupt in Salesforce?

Wat een architect hier beslist

Of Salesforce hier al een standaardobject voor heeft, voordat je een aangepast object bouwt.
De API-naam, één keer gekozen, en een omschrijving geschreven voor mensen en machines.
De recordnaam: Text of Auto Number, met het verwachte volume in gedachten.
Welke optionele functies, API-toegang en zoekfuncties je aanzet, bewust.
Wat de achtervoegsels in een org je vertellen: aangepast, managed, big, extern, persoonsaccount.
Of een package dat je op het punt staat te installeren kan botsen met wat je gebouwd hebt.

Verder lezen

Custom Objects (opens in a new tab) en Custom Fields (opens in a new tab) (Engels), Object Reference (gecontroleerd op 2026-10-13): “the names of custom objects include a suffix of two underscores followed by a lowercase ‘c’”; hetzelfde voor aangepaste velden; en de tabel met standaardobjecten die aangepaste velden ondersteunen.
AppExchange Object Prefixes and the API (opens in a new tab) (Engels), Object Reference (gecontroleerd op 2026-10-13): een namespacevoorvoegsel maakt elk onderdeel in een package uniek; “name__c becomes prefix__name__c”.
Namespace Prefix (opens in a new tab) (Engels), Apex Developer Guide (gecontroleerd op 2026-10-13): namespacevoorvoegsels houden de object- en veldnamen van managed packages gescheiden van die van andere orgs.
Editable Properties After Package Promotion or Installation (opens in a new tab) (Engels), Second-Generation Managed Packaging Developer Guide (gecontroleerd op 2026-10-13): welke eigenschappen van de onderdelen van een package de ontwikkelaar, de abonnee, allebei of geen van beiden kunnen bewerken.
Custom Object Standard Fields (opens in a new tab) (Engels), Salesforce Help (gecontroleerd op 2026-10-12): de standaardvelden die elk aangepast object krijgt (Name, Owner, Created By, Last Modified By, Currency, Division), en waarom Owner verdwijnt aan de detailkant van een hoofd-detailrelatie.
Standard User Licenses (opens in a new tab) (Engels), Salesforce Help (gecontroleerd op 2026-10-12): een Lightning Platform Light App “can’t use the Bulk API or Streaming API”; een Enterprise App “supports record-level sharing, can use the Bulk API and Streaming API.”