Benutzerdefinierte Objekte

Auch in 28 Sprachen

English · Español · 日本語 · Português (Brasil) · Français · 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. — Mit KI erstelltes Bild

Modul 3 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Schauen Sie aufs Mutterschiff: die Standarddatenmodelle · Weiter: Wo liegen diese Daten?

Die Frage, die dieses Modul beantwortet: Wenn Salesforce es nicht hat, was bekommen Sie tatsächlich, wenn Sie Ihr eigenes Objekt bauen?

Im letzten Modul haben wir uns angesehen, was Salesforce bereits gebaut hat. Manchmal hat es nicht, was Sie brauchen. Steve Trucking betreibt Lkw (Trucks), und es gibt kein Standardobjekt für Lkw. Also bauen Sie eines: ein benutzerdefiniertes Objekt.

Das möchte ich Ihnen in diesem Modul zeigen. Ein benutzerdefiniertes Objekt wird in Metadaten angelegt, wie alles andere aus Modul 1, und sobald es existiert, bringt es eine Reihe von Standardfunktionen mit. Es ist keine leere Tabelle. Und der Bildschirm, den Sie ausfüllen, um es anzulegen, stellt Ihnen Architekturfragen, ob Sie es bemerken oder nicht.

Der Bildschirm „New Custom Object“

Gehen Sie zu Setup → Object Manager → Create → Custom Object (Setup → Objekt-Manager → Erstellen → Benutzerdefiniertes Objekt), und Sie bekommen ein langes Formular. Die meisten füllen die ersten beiden Felder aus und klicken auf Speichern. Gehen wir langsamer vor und lesen es.

Label und Plural Label (Bezeichnung und Plural-Bezeichnung). „Truck“ und „Trucks“. Das sehen die Benutzer, in Registerkarten, Seitenlayouts und Berichten. Sie können sie später ohne große Schmerzen ändern.

Object Name (Objektname). Dieser ist anders: Es ist der API-Name, der Name, den Code, Integrationen, Berichte und jetzt auch Agenten verwenden. Tippen Sie „Truck“, und Salesforce macht daraus Truck__c. Ihn später zu ändern heißt, alles zu finden, was sich auf ihn bezieht, und das ist wieder der Umkehrbarkeitstest aus Kapitel 1. Diesen Namen sollten Sie beim ersten Mal richtig wählen.

Description (Beschreibung). Füllen Sie sie aus. Jedes Mal. In Modul 1 habe ich gesagt, dass Metadaten keine Dekoration mehr sind: Die nächste Person in der Administration liest das, und ebenso jedes KI-Werkzeug, das versucht, Ihre Org zu verstehen. Ein benutzerdefiniertes Objekt ohne Beschreibung ist eine Kiste ohne Etikett.

Record Name (Datensatzname). Jedes benutzerdefinierte Objekt hat ein Feld Name, und hier entscheiden Sie, was es ist. Ein Text-Name wie „Truck 117“ oder eine Automatische Nummer (Auto Number) wie T-000184, die Salesforce für Sie ausfüllt. Lesen Sie die Warnung auf diesem Bildschirm: Wenn Sie vorhaben, eine große Menge an Datensätzen über die API einzufügen, sagt Ihnen Salesforce, dass Sie Text verwenden sollen. Da erzählt Ihnen die Plattform etwas über Skalierung, bevor Sie auch nur einen einzigen Datensatz angelegt haben.

Der Abschnitt „Record Name“ des Bildschirms „New Custom Object“: das Feld „Record Name“, der Datentyp Text und die Warnung, den Datentyp Text zu verwenden, wenn Sie eine große Menge an Datensätzen über die API einfügen wollen

Salesforce-Setup, „New Custom Object“: der Abschnitt „Record Name“ mit seiner Warnung (Screenshot, 2026-10-12). Volle Größe

Optional Features (Optionale Funktionen). Allow Reports, Allow Activities, Track Field History, Allow in Chatter Groups (Berichte zulassen, Aktivitäten zulassen, Feldverlauf verfolgen, In Chatter-Gruppen zulassen). Standardmäßig ausgeschaltet. Jede davon ist eine Fähigkeit, die Sie für dieses Objekt einschalten; entscheiden Sie bewusst.

Object Classification (Objektklassifizierung). Allow Sharing, Allow Bulk API Access, Allow Streaming API Access (Freigabe zulassen, Bulk-API-Zugriff zulassen, Streaming-API-Zugriff zulassen), alle standardmäßig eingeschaltet. Der Bildschirm sagt es klar: Sind sie eingeschaltet, ist das Objekt ein Enterprise Application-Objekt; sind sie ausgeschaltet, ist es ein Light Application-Objekt. Diese Namen passen zu den App-Abonnementlizenzen von Salesforce: Eine Lightning Platform Light App hat keine Freigabe auf Datensatzebene und kann weder die Bulk API noch die Streaming API nutzen, eine Enterprise App kann das. Mein Rat: Lassen Sie sie eingeschaltet, es sei denn, Sie wissen genau, warum nicht. Schalten Sie den Bulk-API-Zugriff bei einem Objekt aus, das Sie später in großen Mengen laden, und Sie werden herausfinden, warum er wichtig war.

Deployment Status und Search (Bereitstellungsstatus und Suche). „In Development“ (In Entwicklung) verbirgt das Objekt vor den Benutzern, während Sie es bauen; „Deployed“ (Bereitgestellt) schaltet es live. Und Allow Search (Suche zulassen) ist standardmäßig ausgeschaltet, sodass die Benutzer diese Datensätze in der globalen Suche erst finden, wenn Sie es einschalten. Darüber stolpern die Leute jedes Mal.

Die Standardwerte: die drei API-Einstellungen eingeschaltet, Deployed und Allow Search ausgeschaltet (Screenshot, 2026-10-12). Volle Größe

Klicken Sie auf Speichern, und der Objekt-Manager zeigt Ihnen das Objekt: API-Name Truck__c, ein Häkchen bei Custom (Benutzerdefiniert), die Bezeichnungen, den Bereitstellungsstatus. Schauen Sie aber die linke Seite hinunter: Fields & Relationships, Page Layouts, Lightning Record Pages, Record Types, Validation Rules, Triggers, Flow Triggers, Object Access, Field Access (Felder und Beziehungen, Seitenlayouts, Lightning-Datensatzseiten, Datensatztypen, Validierungsregeln, Trigger, Flow-Trigger, Objektzugriff, Feldzugriff). Diese Liste ist Modul 1, sichtbar gemacht. Ein Objekt ist nicht nur Speicher; es ist der Ort, an dem all dieses Verhalten hängt.

Der Objekt-Manager mit dem Objekt Truck: API-Name Truck__c, Custom angehakt, Bezeichnungen im Singular und Plural und die Liste links von Fields & Relationships bis Validation Rules

Objekt-Manager, Truck: der API-Name Truck__c, Custom und alles, was an einem Objekt hängt (Screenshot, 2026-10-12). Volle Größe

Die Felder, die Sie nicht angelegt haben

Öffnen Sie „Fields & Relationships“ bei einem brandneuen benutzerdefinierten Objekt, und es hat bereits Felder. Jedes benutzerdefinierte Objekt bekommt einen Standardsatz:

Name, der Datensatzname, den Sie gerade gewählt haben, verwendet in Seitenlayouts, Themenlisten, Nachschlagefeldern und Suchergebnissen.
Owner (Eigentümer), der Benutzer oder die Warteschlange, dem bzw. der der Datensatz gehört.
Created By und Last Modified By (Erstellt von und Zuletzt geändert von), die Benutzer, die ihn angelegt und zuletzt geändert haben.
Currency (Währung), wenn Mehrfachwährungen aktiviert sind, und Division (Geschäftsbereich), wenn Ihre Org Geschäftsbereiche verwendet.

Und darunter die Datensatz-ID aus Modul 1 sowie das Erstellungs- und das Änderungsdatum. Exportieren Sie ein paar Datensätze mit dem Data Loader, und Sie sehen sie alle.

Eines davon kann verschwinden. Machen Sie Ihr benutzerdefiniertes Objekt zur Detailseite einer Master-Detail-Beziehung, und das Feld Owner fällt weg: Die Eigentümerschaft kommt dann vom Master-Datensatz. Das ist eine größere Sache, als es klingt, und wir kommen in Modul 7 und 8 darauf zurück.

Präfixe und Suffixe: Was Sie da vor sich haben

Im letzten Modul habe ich gesagt, dass Standardobjekte kein Präfix und kein Suffix haben. Alles andere hat eines, und sobald Sie sie lesen können, sagt Ihnen eine Feldliste genau, was Sie vor sich haben.

So sieht es aus	Das ist es
`Account`, `Case`	Ein Standardobjekt oder Standardfeld: kein Präfix, kein Suffix
`Truck__c`	Ein benutzerdefiniertes Objekt oder ein benutzerdefiniertes Feld wie `Unit_Number__c`
`abc__Inspection__c`	Ein benutzerdefiniertes Objekt aus einem verwalteten Paket: `abc` ist der Namespace des Anbieters
`Delivery_History__b`	Ein Big Object (Modul 4)
`Shipment__x`	Ein externes Objekt: Die Daten liegen in einem anderen System (Modul 4)
`Allergies__pc`	Ein benutzerdefiniertes Kontaktfeld auf einem Personenaccount (Modul 2)
`Truck__r`	Die Beziehung hinter einer benutzerdefinierten Nachschlagebeziehung, wenn Sie ihr in einer Abfrage folgen

Ein paar Dinge fallen auf.

Bis hierhin ist das eine Liste. So unterrichte ich es: als Schichten. Es gibt drei Arten von Objekten, Standard, benutzerdefiniert und aus verwalteten Paketen, und jede davon kann dieselben Arten von Feldern haben: die Standardfelder, mit denen sie kam, und die benutzerdefinierten Felder, die jemand hinzugefügt hat.

Standardobjekte. Account hat kein Präfix und kein Suffix, und seine Standardfelder auch nicht: Name, Industry, OwnerId. Den meisten Standardobjekten können Sie benutzerdefinierte Felder hinzufügen, und jedes, das Sie hinzufügen, endet auf __c: Region__c (Custom Fields (opens in a new tab), auf Englisch). Dieses Suffix schützt Sie. Salesforce fügt Account in seinen Releases neue Standardfelder hinzu, und weil Ihre immer auf __c enden und die von Salesforce nie, kann ein künftiges Standardfeld nie mit einem Feld kollidieren, das Sie bereits haben.

Benutzerdefinierte Objekte. Ihr eigenes Objekt endet auf __c, Truck__c (Custom Objects (opens in a new tab), auf Englisch), und ebenso die benutzerdefinierten Felder, die Sie darauf anlegen: Unit_Number__c. Aber die Felder, mit denen es geboren wurde, die aus dem letzten Abschnitt, sind Standardfelder: Name, OwnerId, CreatedDate, ohne Suffix. Selbst auf Ihrem eigenen Objekt sagt Ihnen das Suffix also, wer jedes Feld angelegt hat.

Objekte aus verwalteten Paketen. Wenn Sie ein verwaltetes Paket von AppExchange installieren, kommen seine Objekte und Felder mit dem Namespace-Präfix des Anbieters: abc__Inspection__c und Felder wie abc__Result__c. Dieses Präfix ist für den Anbieter eindeutig und ändert sich nicht (Namespace Prefix (opens in a new tab), auf Englisch). Wie Salesforce selbst es beschreibt, wird das Präfix jeder Komponente vorangestellt, um sie eindeutig zu machen: Aus name__c wird prefix__name__c (AppExchange Object Prefixes and the API (opens in a new tab), auf Englisch). So können zwei Anbieter beide ein Objekt namens Invoice__c ausliefern, ohne je miteinander oder mit Ihnen zu kollidieren. Die Objekte des Pakets haben trotzdem ihre Standardfelder, Name und OwnerId, ohne Präfix. Ein Paket kann auch eigene Felder mit Präfix zu Standardobjekten hinzufügen, etwa abc__Score__c auf Account. Und Sie können den Objekten eines Pakets Ihre eigenen benutzerdefinierten Felder hinzufügen: Depot__c auf abc__Inspection__c bekommt Ihr Suffix __c, aber nie das Präfix des Anbieters, denn Sie haben es angelegt, nicht der Anbieter (Known Issue: unmanaged custom field on a managed package object (opens in a new tab), auf Englisch).

Click to enlarge

Lesen Sie einen beliebigen API-Namen, und Sie wissen, wer ihn angelegt hat. Kein Suffix: Salesforce. __c ohne Präfix: Ihre Org. abc__ davor: der Anbieter. Das ist bei jeder geplanten Änderung wichtig. Was Ihnen gehört, können Sie ändern. Was Salesforce gehört, konfigurieren und erweitern Sie. Was dem Anbieter gehört, ist größtenteils gesperrt: Ein paar Dinge wie Seitenlayouts und Hilfetext dürfen Sie bearbeiten, aber der größte Teil des Pakets und jeder API-Name gehören dem Anbieter, und seine Upgrades bringen seine Änderungen mit (Editable Properties After Package Promotion or Installation (opens in a new tab), auf Englisch).

Nicht verwaltete Pakete haben keins. Installieren Sie ein nicht verwaltetes Paket, landen seine Objekte in Ihrer Org, als hätten Sie sie selbst gebaut, ohne Präfix. Bringt es ein Truck__c mit und Sie haben schon eines, haben Sie eine Namenskollision. Prüfen Sie das vor der Installation.

Bauen Sie nur, was Salesforce nicht hat

Ein benutzerdefiniertes Objekt anzulegen ist einfach; genau deshalb legen wir meiner Meinung nach zu viele davon an. Der Bildschirm „New Custom Object“ legt Ihnen bereitwillig ein Customer__c in einer Org an, die schon Account hat. Bevor Sie also darauf klicken, stellen Sie die Frage aus dem letzten Modul: Hat das Mutterschiff das schon? Wenn ja, verwenden Sie es. Wenn nicht, bauen Sie es und füllen den ganzen Bildschirm aus wie Architekt:innen.

Das nächste Modul stellt eine noch frühere Frage: Sollten diese Daten überhaupt in Salesforce liegen?

Was Architekt:innen hier entscheiden

Ob Salesforce bereits ein Standardobjekt dafür hat, bevor ein benutzerdefiniertes gebaut wird.
Der API-Name, einmal gewählt, und eine Beschreibung, geschrieben für Menschen und Maschinen.
Der Datensatzname: Text oder Automatische Nummer, mit Blick auf das erwartete Volumen.
Welche optionalen Funktionen, welcher API-Zugriff und welche Suche bewusst eingeschaltet werden.
Was die Suffixe in einer Org Ihnen sagen: benutzerdefiniert, verwaltet, Big Object, extern, Personenaccount.
Ob ein Paket, das Sie gleich installieren wollen, mit dem kollidieren könnte, was Sie gebaut haben.

Weiterlesen

Custom Objects (opens in a new tab) und Custom Fields (opens in a new tab), Object Reference (auf Englisch, geprüft am 2026-10-13): Die Namen benutzerdefinierter Objekte enden auf zwei Unterstriche, gefolgt von einem kleinen „c“; dasselbe gilt für benutzerdefinierte Felder; dazu die Tabelle der Standardobjekte, die benutzerdefinierte Felder unterstützen.
AppExchange Object Prefixes and the API (opens in a new tab), Object Reference (auf Englisch, geprüft am 2026-10-13): Ein Namespace-Präfix macht jede Paketkomponente eindeutig; aus name__c wird prefix__name__c.
Namespace Prefix (opens in a new tab), Apex Developer Guide (auf Englisch, geprüft am 2026-10-13): Namespace-Präfixe halten die Objekt- und Feldnamen verwalteter Pakete von denen anderer Orgs getrennt.
Editable Properties After Package Promotion or Installation (opens in a new tab), Second-Generation Managed Packaging Developer Guide (auf Englisch, geprüft am 2026-10-13): welche Eigenschaften der Komponenten eines Pakets das Entwicklungsteam, die abonnierende Org, beide oder keiner von beiden bearbeiten können.
Custom Object Standard Fields (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): die Standardfelder, die jedes benutzerdefinierte Objekt bekommt (Name, Owner, Created By, Last Modified By, Currency, Division), und warum Owner auf der Detailseite einer Master-Detail-Beziehung entfernt wird.
Standard User Licenses (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): Eine Lightning Platform Light App kann weder die Bulk API noch die Streaming API nutzen; eine Enterprise App unterstützt Freigabe auf Datensatzebene und kann die Bulk API und die Streaming API nutzen.