Die Standarddatenmodelle
Auch in 28 Sprachen
English · Español · 日本語 · Português (Brasil) · 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)
Modul 2 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Die Salesforce-Datenplattform: mehr als eine Datenbank · Weiter: Selbst gebaut: benutzerdefinierte Objekte
Die Frage, die dieses Modul beantwortet: Was hat Salesforce bereits für Sie modelliert, und wie ist es aufgebaut?
In Modul 1 habe ich Ihnen gesagt: Schauen Sie aufs Mutterschiff. Bevor Sie etwas erfinden, schauen Sie, wie Salesforce selbst es tut. In diesem Modul schauen wir tatsächlich hin. Salesforce hat bereits einen grossen Teil des Geschäfts für Sie modelliert, in seinen Standardobjekten, und zwei dieser Modelle erledigen in den meisten Orgs, in die ich komme, den Grossteil der Arbeit: das Sales-Modell und das Service-Modell. Bevor Sie entscheiden können, ob etwas ein benutzerdefiniertes Objekt verdient, müssen Sie wissen, was schon da ist. Darum geht es in den nächsten beiden Modulen.
Was ein Objekt zum Standardobjekt macht
Abschnitt betitelt „Was ein Objekt zum Standardobjekt macht “Ein Standardobjekt ist ab Werk vorhanden. Salesforce hat es gebaut, es hat einen festgelegten Zweck und bringt seine eigenen Felder und Beziehungen mit. Sie können ihm Felder hinzufügen, Automatisierung darum herum bauen und seine Layouts ändern, aber Sie können es nicht neu entwerfen: Die Standardfelder und -beziehungen gehören Salesforce.
Schauen Sie sich die Namen an. Account, Contact, Case. Kein Präfix, kein Suffix. Damit hält sich Salesforce diesen Raum frei. Alles, was wir bauen, endet auf __c, sodass Salesforce jederzeit neue Standardobjekte hinzufügen kann, ohne je mit etwas in Ihrer Org zu kollidieren. Und das tut es, mit jedem Release.
Irgendwann hat jemand ein Produktobjekt gebaut, das nicht funktioniert hat und zurückgelassen werden musste. Deshalb lautet der API-Name Product2. Das ist mein erster Lackmustest, wenn mir jemand sagt, er kenne Salesforce.
Das Sales-Modell
Abschnitt betitelt „Das Sales-Modell “Fangen Sie links an, beim Lead: jemand, der Kunde werden könnte. Ein Lead ist eigentlich noch kein Teil des Modells. Er ist ein Wartebereich. Wenn Sie ihn konvertieren, erstellt Salesforce die echten Datensätze: einen Account, einen Kontakt und, falls es ein Geschäft gibt, eine Opportunity. Deshalb zeichne ich den Lead abseits.
Der Account ist das Unternehmen. Seine Kontakte sind die Menschen dort. Eine Opportunity ist ein Geschäft mit diesem Account. Bis hierhin nichts Unerwartetes.
Dann wird es interessant. Was steckt in dem Geschäft? Jede Zeile ist ein Opportunity-Produkt, und ein Opportunity-Produkt zeigt nicht direkt auf ein Produkt. Es zeigt auf einen Preisbucheintrag: dieses Produkt, zu diesem Preis, in diesem Preisbuch. Der Preisbucheintrag sitzt zwischen dem Produkt und dem Preisbuch, sodass dasselbe Produkt im Standardpreisbuch einen Preis und in Ihrem Partner-Preisbuch einen anderen haben kann.
Das sind zwei Beziehungen, die zu Dingen geworden sind, eine nach der anderen. Erinnern Sie sich an die Lieferposition aus Kapitel 2, zwischen Lieferung und Produkt, und an den Hundetrick zwischen dem Hund und dem Trick? Salesforce hat hier genau dasselbe getan, zweimal: das Opportunity-Produkt zwischen der Opportunity und dem Preisbucheintrag, und den Preisbucheintrag zwischen dem Produkt und dem Preisbuch. Wenn Sie das lesen können, können Sie den grössten Teil des Standarddatenmodells lesen.
Hier diese Kette aus der Nähe, mit den Feldern, die sie zusammenhalten:
Eine Regel, über die Menschen stolpern: Es gibt ein Standardpreisbuch, und ein Preisbucheintrag in jedem anderen Preisbuch kann einfach den Standardpreis des Produkts verwenden. Wissen Sie, welches Preisbuch eine Opportunity verwendet, bevor Sie ihre Produkte laden.
Das Service-Modell
Abschnitt betitelt „Das Service-Modell “Jetzt die andere Seite des Hauses. Derselbe Account, dieselben Kontakte. Wenn etwas schiefgeht, eröffnet der Kunde einen Kundenvorgang (Case).
Der Kundenvorgang betrifft meist etwas, das der Kunde besitzt, und dafür hat Salesforce ein Objekt: das Asset. In Modul 5 nenne ich es das Standardobjekt, das Menschen übersehen. Es ist etwas, das der Kunde besitzt, ob er es bei Ihnen gekauft hat oder nicht.
Und worauf hat der Kunde Anspruch? Das ist die Berechtigung (Entitlement): der Support, den ein Account erhalten darf, oft gebunden an ein Asset, ein Produkt oder einen Servicevertrag. Hängen Sie eine Berechtigung an einen Kundenvorgang, und der Kundenvorgang weiss, welches Support-Niveau ihm zusteht.
Schauen Sie auf die Linie, die vom Kundenvorgang zu ihm selbst zurückführt. Jeder Kundenvorgang hat ein Feld Parent Case (Übergeordneter Kundenvorgang), und es zeigt auf einen anderen Kundenvorgang. Das ist eine Selbstreferenz (Self-Lookup): eine Beziehung von einem Objekt zu sich selbst. Sie verwirrt viele Menschen, wenn sie sie zum ersten Mal sehen, deshalb hier die zwei Gründe, aus denen ich sie verwende.
Erstens: ein grosses Problem, das in kleinere zerfällt. Der Kunde meldet, dass die ganze Installation ausgefallen ist. Wir eröffnen Unter-Kundenvorgänge für das Netzwerk, die Hardware und die Konfiguration, jeder wird für sich bearbeitet, und alle lösen sich nach oben auf: Der übergeordnete Kundenvorgang ist erst erledigt, wenn sie es sind.
Zweitens: Historie. Ein Kundenvorgang wurde letzten Monat geschlossen, und jetzt ist dasselbe Problem wieder da. Der neue Kundenvorgang zeigt zurück auf den ursprünglichen, sodass alle, die ihn öffnen, sehen, dass das schon einmal passiert ist und was dagegen getan wurde.
Auf Selbstreferenzen kommen wir zurück, wenn es in Modul 7 um Beziehungen geht.
Beachten Sie, dass Account und Kontakt in beiden Diagrammen an derselben Stelle sitzen. Es sind dieselben Datensätze. Vertrieb und Service schauen auf denselben Kunden, von verschiedenen Seiten des Hauses. Das ist eines der stärksten Argumente dafür, beim Standard zu bleiben: Die Modelle wurden gebaut, um sich zu treffen.
Dateien und Anhänge
Abschnitt betitelt „Dateien und Anhänge “Nicht alles an einem Datensatz ist ein Feld. Verträge, Fotos, PDFs und Tabellen sind Dateien, und sie gehören in Salesforce Files, nicht in das alte Anhangsmodell (Attachments), das veraltet ist. Liegt das Dokument bereits in SharePoint Online, OneDrive, Google Drive oder Box, ermöglicht Files Connect den Benutzern, es aus Salesforce heraus zu erreichen, ohne es hineinzukopieren.
Dateien werden anders gezählt als Datensätze. Salesforce teilt den Speicher in zwei Teile: Der Dateispeicher enthält Anhänge, Files, Salesforce CRM Content, Chatter-Dateien und Ähnliches, und der Datenspeicher enthält Ihre Datensätze. Der Dateispeicher wächst schnell, wenn jeder Datensatz Fotos oder Scans bekommt, deshalb gehören grosse Mengen an Bildern, etwa die Fotos aus einer Aussendienst-App, oft ganz ausserhalb von Salesforce, und Salesforce behält nur einen Link. Modul 4 kommt darauf zurück.
Zwei Spalten oder zweihundert
Abschnitt betitelt „Zwei Spalten oder zweihundert “Auch der Datenspeicher wird anders gezählt als in einer Datenbank. In einer normalen Datenbank ist eine Tabelle mit zwei Spalten und einer Million Zeilen klein, und eine Tabelle mit hundert Spalten und einer Million Zeilen ist ein Elefant. Salesforce gewichtet beide gleich: Die meisten Datensätze zählen als etwa 2 KB, egal wie viele Felder sie haben. Es gibt Ausnahmen. Eine Kampagne zählt mehr, eine E-Mail-Nachricht zählt mit ihrer tatsächlichen Grösse, und ein Personenaccount zählt als etwa 4 KB, weil er ein Account und ein Kontakt ist.
Hier ein Tipp. Wann immer ich in eine neue Org komme, gehe ich als Erstes unter anderem zu Setup → Storage Usage (Speichernutzung). Ich bitte einen Kunden sogar schon im ersten Gespräch um einen Screenshot. Dieser Bildschirm lügt nicht. Er zeigt Ihnen, welche Objekte wachsen und welche schon die Elefanten sind.
Personenaccounts: wenn der Kunde eine Person ist
Abschnitt betitelt „Personenaccounts: wenn der Kunde eine Person ist “Das Modell aus Account und Kontakt funktioniert wunderbar für ein Unternehmen und die Menschen dort. Aber was, wenn Ihr Kunde kein Unternehmen ist? Was, wenn es eine Person ist?
Dafür gibt es den Personenaccount: ein Account und ein Kontakt, zu einem einzigen Datensatz zusammengefasst, für einzelne Menschen. Die Kontaktfelder kommen mit, und die benutzerdefinierten erscheinen mit einem eigenen Suffix, __pc. Jeder Personenaccount zählt sowohl gegen den Account- als auch gegen den Kontaktspeicher, weil er darunter beides ist.
Eine Warnung, bevor Sie sie einschalten: Sind Personenaccounts einmal aktiviert, lassen sie sich nicht mehr deaktivieren. Das ist der Umkehrbarkeitstest aus Kapitel 1 in seiner reinsten Form. Modul 5 gibt Ihnen meine Position dazu, wann sie sich lohnen.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welche Teile des Geschäfts Salesforce bereits modelliert hat, bevor irgendetwas Neues entworfen wird.
- Ob ein Konzept im Sales-Modell, im Service-Modell oder in beiden landet, im Wissen, dass sie sich Account und Kontakt teilen.
- Wo Dokumente und Bilder liegen: in Salesforce Files, in einem angebundenen Dateisystem oder ausserhalb der Plattform mit einem Link.
- Was die Daten an Speicher kosten werden, so gezählt, wie Salesforce zählt: Datensätze, nicht Spalten.
- Ob der Kunde ein Unternehmen oder eine Person ist, bevor Sie etwas einschalten, das sich nicht mehr ausschalten lässt.
Und wenn Salesforce nicht hat, was Sie brauchen? Dann bauen Sie es. Darum geht es als Nächstes.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- OpportunityLineItem (opens in a new tab), Object Reference for the Salesforce Platform (auf Englisch, geprüft am 2026-10-12): ein Eintrag in der Liste der Product2-Produkte, die einer Opportunity zugeordnet sind; der Preisbucheintrag ist erforderlich.
- PricebookEntry (opens in a new tab), Object Reference (auf Englisch, geprüft am 2026-10-12): eine Verbindung zwischen einem Pricebook2 und einem Product2; ein Eintrag kann den Standardpreis verwenden.
- Case (opens in a new tab), Object Reference (auf Englisch, geprüft am 2026-10-12): ParentId, die ID des übergeordneten Kundenvorgangs in der Hierarchie, mit der Bezeichnung Parent Case; eine Nachschlagebeziehung auf Case.
- Entitlement (opens in a new tab), Object Reference (auf Englisch, geprüft am 2026-10-12): der Kundensupport, den ein Account oder Kontakt erhalten darf, möglicherweise auf Grundlage eines Assets, eines Produkts oder eines Servicevertrags.
- Data and Storage Resources (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): was Dateispeicher und Datenspeicher umfassen.
- Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): Die meisten Salesforce-Datensätze belegen etwa 2 KB Datenspeicher; Personenaccounts etwa 4 KB.
- Enable Person Accounts (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-10-12): Sind Personenaccounts einmal aktiviert, lassen sie sich nicht mehr deaktivieren.
- Files Connect FAQ (opens in a new tab), Salesforce-Hilfe (auf Englisch, geprüft am 2026-09-25).