Das richtige Objekt wählen
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 5 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Wo liegen diese Daten? · Weiter: Auch Felder sind Architektur
Die Frage, die dieses Modul beantwortet: Welche Art von Salesforce-Objekt sollte aus diesem Geschäftskonzept werden, und was erlauben die Lizenzen?
Eines der leichtesten Dinge in Salesforce ist, ein benutzerdefiniertes Objekt zu erstellen. Genau deshalb glaube ich, dass wir zu viele davon erstellen.
Sie sitzen in einer Anforderungssitzung, und jemand sagt: «Wir müssen unsere Distributoren erfassen.» Neues benutzerdefiniertes Objekt: Distributor. Fertig. Nur möchte ich, dass in der Architektur zuerst eine andere Frage gestellt wird: Was ist ein Distributor? Es ist ein Unternehmen. Salesforce hat schon eine ziemlich gute Art, ein Unternehmen darzustellen. Sie heisst Account. Das heisst nicht, dass die Antwort immer Account ist. Aber wenn ich erklären muss, warum ein Unternehmen kein Account ist, möchte ich einen besseren Grund als «Das Geschäft nennt sie Distributoren».
Hier trifft das logische Modell aus Kapitel 2 auf die Plattform, und meine Ausgangsposition ist einfach: Wenn das Geschäftskonzept sauber zum vorgesehenen Zweck eines Standardobjekts passt, beginnen Sie dort.
Beginnen Sie mit der Bedeutung
Abschnitt betitelt „Beginnen Sie mit der Bedeutung “Selbst wenn etwas ein Objekt verdient, verdient es nicht automatisch ein benutzerdefiniertes Objekt. Fragen Sie, was das Ding eigentlich darstellt. Ein Unternehmen oder eine Organisation jeder Form? Beginnen Sie mit Account. Eine Person, die mit dieser Organisation arbeitet? Kontakt. Etwas, das ein Kunde besitzt oder gekauft hat? Asset. Etwas, das Sie verkaufen wollen? Jetzt gehört die Opportunity ins Gespräch.
Deshalb haben wir in Modul 2 zuerst aufs Mutterschiff geschaut. Diese Modelle passen nicht zu jedem Geschäft, aber wir sollten sie nicht ignorieren, nur weil es sich sauberer anfühlt, ein eigenes zu bauen. Fragen Sie vor «New Custom Object» (Neues benutzerdefiniertes Objekt), wie Salesforce dieses Konzept modelliert, was um dieses Modell herum gebaut wurde und was Sie aufgeben würden, wenn Sie es ersetzen.
Der Test der sauberen Passung
Abschnitt betitelt „Der Test der sauberen Passung “Mein Test ist eine Frage: Passt dieses Geschäftskonzept sauber zum vorgesehenen Zweck des Standardobjekts? Wenn ja, neige ich zum Standardobjekt.
Ein Distributor ist ein Unternehmen, mit dem wir eine Beziehung haben, also passt Account sauber. Es stört mich nicht, dass die Benutzer ein Unternehmen Distributor nennen, ein anderes Lieferant, ein anderes Handelspartner und ein anderes Kunde. Das sind Geschäftsrollen, und sie brauchen keine vier physischen Objekte. Verschiedene Geschäftsnamen bedeuten nicht automatisch verschiedene Datenstrukturen. Ein Typ, ein Datensatztyp oder eine Beziehung kann den Unterschied tragen.
Der Test funktioniert auch in die andere Richtung. In Kapitel 1 habe ich Ihnen eine Frage mitgegeben: Das Geschäft eines Kunden hat viele Lieferorte. Sollte jeder Lieferort ein Account sein oder ein benutzerdefiniertes Objekt?
Ein Account gibt Ihnen viel. Sie bekommen die Adressfelder und alles, was bereits eine Account-Adresse erwartet: Berichte, Karten, Integrationen. Aber Sie bekommen auch den Ballast: viele Felder, Freigabe, Hierarchie, Eigentümerschaft, alles, was an einem Account hängt, und das meiste davon ist für eine separate Adresse nicht relevant. Sie würden viel schweres Zeug mitschleppen, das Sie nicht nutzen, nur für eine weitere Adresse.
Ein benutzerdefiniertes Objekt, ein untergeordnetes Objekt des Accounts, kann schlank sein: nur die Adressfelder, ein Ort, an den wir liefern, mit einem eigenen Lebenszyklus, den ich unabhängig steuern kann.
Es ist also eine Abwägung: das Gewicht, das Sie aufnehmen, gegen den Wert, den Sie bekommen. Wenn ich nur eine Adresse mit eigenem Lebenszyklus brauche, gehe ich dort zu benutzerdefiniert.
Genauso bei Unterpunkten eines Kundenvorgangs. Wenn jeder Unterpunkt wirklich ein Kundenvorgang ist, von Servicemitarbeitenden bearbeitet, mit eigenem Status und eigenem Service-Level, verschachteln Sie sie über den übergeordneten Kundenvorgang (Parent Case) aus Modul 2. Wenn es aber nur ein Checklistenpunkt ist, den niemand als Kundenvorgang bearbeitet, trägt ein vollständiger Kundenvorgang viel mit sich, das er nie nutzt, und ein einfaches benutzerdefiniertes untergeordnetes Objekt wiegt vielleicht weniger. Nicht weil benutzerdefiniert sauberer wäre. Sondern weil die Bedeutung eine andere ist oder das Gewicht nicht passt.
Standardobjekte bringen Gepäck mit
Abschnitt betitelt „Standardobjekte bringen Gepäck mit “Wenn Sie ein Standardobjekt wählen, wählen Sie mehr als seine Felder. Sie wählen etwas, das die Produkte von Salesforce bereits verstehen: Berichte, Automatisierung, eingebaute Beziehungen, Produktfunktionen, AppExchange-Pakete und was Salesforce als Nächstes baut. Das kann enorm wertvoll sein.
Standardobjekte bringen auch Meinungen mit: bestehendes Verhalten, Beziehungen, Sicherheitsaspekte, manchmal Lizenzanforderungen und Funktionen, die Sie nicht brauchen. «Immer Standardobjekte verwenden» ist also nicht meine Regel. Ich habe keine «Immer»-Regel. Ich habe eine Neigung: Verwenden Sie das Standardobjekt, wenn die Bedeutung sauber passt und das Plattformverhalten darum herum dem Entwurf hilft, statt gegen ihn zu arbeiten. Wenn ich fünf Jahre damit verbringe, eine Opportunity dazu zu bringen, sich wie etwas zu verhalten, das keine Verkaufschance ist, habe ich durch den Standard nichts gewonnen. Ich habe nur den falschen Kompromiss in die andere Richtung geschlossen.
Asset ist ein gutes Beispiel
Abschnitt betitelt „Asset ist ein gutes Beispiel “Asset ist eines der Standardobjekte, die übersehen werden. Einfacher kann ich es nicht sagen: Es ist ein Ding, das der Kunde hat. Vielleicht hat er es bei uns gekauft, vielleicht nicht. Das Produkt eines Wettbewerbers beim Kunden interessiert mich trotzdem, weil ich es warte, oder ersetzen will, oder seinen installierten Bestand verstehen muss. Wenn ich Customer_Product__c erstelle, ohne zuerst Asset anzuschauen, habe ich eine Architekturfrage übersprungen. Asset gewinnt nicht automatisch, aber es verdient eine Prüfung.
Personenaccounts: Wann ist die Person der Account?
Abschnitt betitelt „Personenaccounts: Wann ist die Person der Account? “In Modul 2 haben wir Personenaccounts kennengelernt: ein Account und ein Kontakt in einem Datensatz, für Kunden, die Einzelpersonen sind. Jetzt die Entscheidung.
Meine Position: Im B2C kommt man kaum ohne sie aus. Mit Accounts und Kontakten kommt so viel standardmässig mit, dass sich Kosten und Aufwand lohnen. Und es gibt Kosten: etwa doppelt so viel Speicher wie ein Firmenaccount, ein Schalter, den Sie nicht wieder ausschalten können, und manche externen Lizenzen können sie nicht nutzen. Partner Community lässt sich nicht mit Personenaccounts verwenden (Experience Cloud User Licenses (opens in a new tab), auf Englisch). Die Frage ist also nicht «Haben wir Menschen in unserer Datenbank?» Jede Org hat Menschen. Sie lautet: «Ist die Person in diesem Geschäft tatsächlich der Account?» Dass ein Kontakt eine Person ist, macht ihn nicht zum Personenaccount. Die Geschäftsbeziehung tut es.
Jetzt mache ich alles kompliziert: Lizenzen
Abschnitt betitelt „Jetzt mache ich alles kompliziert: Lizenzen “Bisher: das Konzept finden, nach der saubersten Standardpassung suchen, benutzerdefiniert werden, wenn die Bedeutung nicht passt. Jetzt die Folgefrage der Architektur: Wer muss es benutzen? Sie können ein schönes Modell entwerfen und dann feststellen, dass die Hälfte der Menschen, die die Daten brauchen, für die gewählten Objekte nicht lizenziert ist. Lizenzen sind Teil des Datenmodells.
Drei interne Lizenzen
Abschnitt betitelt „Drei interne Lizenzen “Beginnen Sie mit Ihren eigenen Leuten. Innerhalb des Unternehmens gibt es drei Lizenztypen, die alle Architekt:innen im Schlaf kennen sollten, denn sie bestimmen, was jeder Benutzer sehen und tun kann, und damit, worauf sich Ihr Datenmodell verlassen kann.
Sales Cloud (jetzt Agentforce Sales). Diese Benutzer haben die vollständige Benutzerlizenz Salesforce: Standard-CRM-Objekte und jede Standard- oder benutzerdefinierte App. Das sind Leads, Opportunities und Prognosen zusätzlich zu Accounts und Kontakten, und sogar Kundenvorgänge: Der Vertrieb kann vor einem Gespräch die offenen Kundenvorgänge eines Kunden sehen. Um Kampagnen zu erstellen und durchzuführen, braucht es noch ein Stück, die Funktionslizenz Marketing User.
Service Cloud (jetzt Agentforce Service). Dieselbe Salesforce-Benutzerlizenz, für den Service eingerichtet. Kundenvorgänge stehen im Mittelpunkt, bearbeitet in der Service Console: Die Funktionslizenz Service Cloud User öffnet die Salesforce Console for Service. Hier leben die Service-Level-Vereinbarungen, über die Berechtigungsverwaltung (Entitlement Management) und Meilensteine, und hier kommt Knowledge ins Spiel, das die meisten Editionen als Zusatz kaufen.
Platform (Salesforce Platform). Für Menschen, die Ihre benutzerdefinierten Apps brauchen, nicht das CRM. Sie bekommen Accounts, Kontakte, Berichte, Dashboards, Dokumente und jede benutzerdefinierte App in der Org. Was sie nicht bekommen: Prognosen, Leads, Kampagnen und Opportunities. Sie kostet weniger, und genau deshalb laufen so viele grosse benutzerdefinierte Apps darauf, und genau deshalb kann sie Ihr Datenmodell kalt erwischen.
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| Benutzerlizenz | Salesforce | Salesforce | Salesforce Platform |
| Gebaut für | Verkaufen | Kundenbetreuung | Benutzerdefinierte Apps |
| Accounts, Kontakte | Ja | Ja | Ja |
| Leads, Opportunities, Prognosen | Ja | Ja | Nein |
| Kundenvorgänge | Ja, um die Kundenvorgänge eines Kunden zu sehen | Im Mittelpunkt, in der Service Console | Nein |
| Service-Level-Vereinbarungen | Nein | Ja, Berechtigungen und Meilensteine | Nein |
| Benutzerdefinierte Objekte und Apps | Ja | Ja | Ja |
Lesen Sie die Tabelle so, wie es Architekt:innen tun. Wenn eine grosse Gruppe von Benutzern auf Platform ist, ist jeder Entwurf, der ihre Arbeit auf eine Opportunity legt, kaputt, bevor er beginnt. Wenn Führungskräfte SLA-Zahlen brauchen, entscheidet ihre Lizenz, ob sie sie sehen können. Diese drei Typen bestimmen das Verhalten.
Wenn die Lizenz das Objekt entscheidet
Abschnitt betitelt „Wenn die Lizenz das Objekt entscheidet “Die Opportunity ist das Opfer, dem ich am häufigsten begegnet bin. Sie haben es in der Tabelle gesehen: Platform-Benutzer bekommen sie nicht (Standard User Licenses (opens in a new tab), auf Englisch), und Customer-Community-Benutzer können ebenfalls nicht mit ihr arbeiten. Die Anforderung sieht also aus wie eine Opportunity, jemand sagt «Nehmen wir die Opportunity», und dann frage ich, wer Zugriff braucht. Wenn eine grosse Gruppe Platform- oder Customer-Community-Lizenzen hat, ist die Lizenz kein Einkaufsdetail mehr. Sie ist eine Architektureinschränkung, und meist drängt sie den Entwurf zu einem benutzerdefinierten Objekt.
Es funktioniert auch nach oben. Im Kurs frage ich: Der CEO will hübsche Dashboards; Sales-Lizenz oder Service? Ein Sales-Benutzer sieht die Vertriebsobjekte und sogar Kundenvorgänge, also ist Sales für Vertriebs-Dashboards und die Zahl offener Vorgänge in Ordnung. Aber sobald die Führungskraft SLA-Kennzahlen will (wie lange, bis ein Vorgang sein Service-Level verletzt), liegen diese Daten in Berechtigungen und Meilensteinen (Entitlements and Milestones), und die Berechtigungsverwaltung braucht Agentforce Service, früher Service Cloud (Supported Editions for Service Features (opens in a new tab), auf Englisch). Jetzt rüsten Sie die Lizenzen der Führungskräfte auf. Hören Sie auf die fachliche Anforderung, und wissen Sie, welche Lizenz unter den Daten liegt, die sie braucht.
Das Stadion
Abschnitt betitelt „Das Stadion “Ich stelle mir Lizenzen wie Plätze in einem Stadion vor. Alle sehen dasselbe Spiel. Wenn ich die teuren Plätze in der Mitte kaufe, sehe ich beide Mannschaften aus der Nähe. Wenn ich oben in der Ecke auf den billigen Rängen sitze, sind die Sitze nicht gepolstert und ich schaue durchs Fernglas.
Das sind die externen Lizenzen, für Menschen ausserhalb des Unternehmens: Kunden und Partner, die sich bei einer Experience-Cloud-Site anmelden. Drei davon sollten Sie kennen.
Customer Community: die billigen Ränge. Gebaut für grosse Zahlen externer Benutzer, die Kundenvorgänge und Knowledge brauchen: ein Kunde, der nach seinem Supportfall schaut. Die Plätze kosten etwa die Hälfte und können an riesige Zahlen von Benutzern gehen. Was verlieren Sie dort oben? Berichte, Dashboards und die Freigabetabelle: die rollenbasierte Freigabe, die die höheren Stufen bekommen. Mit Personenaccounts funktioniert sie.
Customer Community Plus: etwa auf halber Höhe. Salesforce beschreibt sie als die Lizenz für externe Benutzer, die Berichte und Dashboards und die Standardfreigabe brauchen: ein Kunde, der den Zugriff anderer verwaltet oder seine Zahlen sehen muss.
Partner Community: noch näher dran, für Business-to-Business, mit Zugriff auf Vertriebsdaten. Partner arbeiten an Leads und Opportunities: Sie registrieren Deals und führen mit Ihnen Kampagnen durch. Das ist der externe Platz, der an die Vertriebsobjekte heranreicht. Ein Haken: Sie lässt sich nicht mit Personenaccounts verwenden (Experience Cloud User Licenses (opens in a new tab), auf Englisch).
Der Fehler ist, so zu entwerfen, als hätten alle das teure Ticket, und dann bei der Umsetzung festzustellen, dass die meisten Ihrer Benutzer nicht in den Bereich kommen, in den Sie ihre Daten gelegt haben. Dann haben Sie drei Möglichkeiten: andere Plätze kaufen, das Erlebnis verlagern oder das Modell umgestalten. Alle drei sind Architektur.
Wie sie bezahlen, ändert den Entwurf
Abschnitt betitelt „Wie sie bezahlen, ändert den Entwurf “Es gibt noch eine Frage, die gern vergessen wird: Wie werden sich diese Benutzer anmelden? Externe Lizenzen gibt es in zwei Formen. Mitgliederbasiert: Sie zahlen pro Benutzer, was zu 500 Partnern passt, die sich jeden Tag anmelden. Anmeldungsbasiert: Sie kaufen eine Zahl von Anmeldungen pro Monat, was zu fünf Millionen Kunden passt, die sich ein paarmal im Jahr anmelden. Mehrere Anmeldungen am selben Tag zählen trotzdem als eine Anmeldung (Experience Cloud User Licenses (opens in a new tab), auf Englisch).
Wenn also jemand sagt «Wir bauen ein Kundenportal», ist meine nächste Frage nicht, welche Vorlage. Sie lautet: Wer sind die Kunden, wie viele, wie oft kommen sie, welche Daten brauchen sie, und was dürfen sie damit tun?
Wenn die Lizenz das Modell formt
Abschnitt betitelt „Wenn die Lizenz das Modell formt “Manchmal wählt die Lizenz nicht nur das Objekt; sie biegt das ganze Modell. Manche Plattformlizenzen beschränken Benutzer auf eine benutzerdefinierte App mit bis zu zehn benutzerdefinierten Objekten (zum Beispiel Lightning Platform – One App; Standard User Licenses (opens in a new tab), auf Englisch).
Bei einem frühen Projekt für ein grosses Dienstleistungs- und Bauunternehmen mussten wir so etwas wie LinkedIn für die ganze Belegschaft bauen: die Positionen, Fähigkeiten, Zertifizierungen, Sprachen und Projekte aller, damit man den Brückenbauer finden konnte, der in einem bestimmten Land zertifiziert ist. Ohne Grenze hätte ich ein Objekt für Benutzer-Position, Benutzer-Fähigkeit, Benutzer-Zertifizierung, Benutzer-Sprache und Benutzer-Projekt gebaut, dazu Referenzlisten für Zertifizierungen und Projekte. Unter einer Zehn-Objekte-Lizenz, und mit der Ansage, sie nicht alle zu verbrauchen, ging das nicht. Also wurde es ein Ratespiel: Mit wie wenigen Objekten kann ich das bauen? Die Antwort war zwei. Ein Referenzobjekt mit einem Datensatztyp für jede Art von Liste (Position, Fähigkeit, Zertifizierung, Sprache, Projekt) und ein Objekt für Benutzerattribute mit passenden Datensatztypen, das darauf verweist.
Es war nicht das optimale Modell. Es war mühsam auszuwerten, und ich hätte es lieber sauberer gehabt. Aber das hat die Lizenz erlaubt. Ich nenne das Schweizer-Taschenmesser-Objekte: Behalten Sie das Muster in der Hinterhand, und wenn die Grenzen keinen Platz lassen, schlagen Sie das Glas ein und trennen Sie über Datensatztypen. Wissen Sie nur, was Sie dafür hergeben. Unterschiedliche Berechtigungen pro Datensatztyp können Sie trotzdem zwingen, das Objekt aufzuteilen.
Menschen sind nicht mehr die einzigen Benutzer
Abschnitt betitelt „Menschen sind nicht mehr die einzigen Benutzer “Eine weitere Lizenzfrage ist wichtig geworden: Was ist mit den Dingen, die keine Menschen sind? Integrationen haben Identitäten. Agenten haben Identitäten. Salesforce hat jetzt eine Lizenz Salesforce Integration für Integrationen zwischen Systemen: nur API, nicht für Menschen, mit fünf enthaltenen Lizenzen in jeder Org der Enterprise, Unlimited und Performance Edition (Standard User Licenses (opens in a new tab), auf Englisch). Fragen Sie also nicht nur, welche Benutzer Zugriff brauchen. Fragen Sie, welche Identitäten Zugriff brauchen: eine Person, ein Kunde, ein Partner, eine Integration, ein Agent. Und dann, was jede davon sehen und tun muss.
Über die Prüfung hinaus: Was KI ändert. Da Agenten Daten zunehmend selbst nutzen und erzeugen, geht es bei Objektwahl und Lizenzen nicht mehr nur um Bildschirme für Menschen. Wissen Sie, unter welcher Identität der Agent läuft, was diese Identität erreichen kann und ob das Modell die Daten, die er braucht, hinter ein Objekt oder eine Berechtigung legt, die er nicht nutzen kann.
Steve Trucking: ein leichter und ein schwerer Fall
Abschnitt betitelt „Steve Trucking: ein leichter und ein schwerer Fall “Steve Trucking arbeitet mit Handelspartnern. Was ist ein Handelspartner? Ein Unternehmen. Leicht: Account. Ich erstelle kein Retail_Partner__c, nur weil jemand das Wort «Partner» verwendet hat.
Jetzt der Empfänger, die Person, die den Kühlschrank bekommt. Kontakt? Personenaccount? Etwas anderes? Eine Million neue Empfänger im Jahr, die Kunden der Handelspartner sind, nicht unsere. Genau bei so einer Frage möchte ich nicht zu einem Objekt springen, bevor ich die Beziehung, den Zugriff und das Volumen verstehe. Wir entscheiden das am Checkpoint von Teil 1.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Ob ein Geschäftskonzept sauber zum vorgesehenen Zweck eines Standardobjekts passt oder ob seine Bedeutung oder sein Gewicht anders ist.
- Ob verschiedene Geschäftsbezeichnungen verschiedene Entitäten sind oder nur verschiedene Rollen derselben.
- Ob jede Person, jeder externe Benutzer, jede Integration und jeder Agent, der die Daten braucht, das gewählte Objekt mit den geplanten Lizenzen erreichen kann.
- Wie die Benutzergruppe und das Anmeldemuster (mitgliederbasiert oder anmeldungsbasiert) Lizenz und Modell formen.
- Wann eine Lizenzgrenze ein nicht optimales Modell rechtfertigt und was dieser Tausch bei Berichten und Berechtigungen kostet.
Es geht nicht darum, dass Standardobjekte gut und benutzerdefinierte schlecht sind. Es geht darum, dass die Wahl Folgen hat, und manchmal wird sie gar nicht vom Substantiv entschieden, sondern von den Menschen, und den Maschinen, die es nutzen müssen.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce-Hilfe, Standard User Licenses (opens in a new tab) (auf Englisch), geprüft am 2026-10-02, erneut geprüft am 2026-10-12: Platform-Benutzer haben keinen Anspruch auf Prognosen, Leads, Kampagnen und Opportunities; eine benutzerdefinierte App mit bis zu 10 benutzerdefinierten Objekten; fünf Salesforce-Integration-Lizenzen in jeder Org der Enterprise Edition.
- Salesforce-Hilfe, Experience Cloud User Licenses (opens in a new tab) (auf Englisch), geprüft am 2026-10-02, erneut geprüft am 2026-10-12: Partner Community lässt sich nicht mit Personenaccounts verwenden; Customer Community Plus für Berichte, Dashboards und Standardfreigabe; mehrere Anmeldungen an einem Tag zählen als eine.
- Salesforce-Hilfe, Supported Editions for Service Features (opens in a new tab) (auf Englisch), geprüft am 2026-10-02, erneut geprüft am 2026-10-12: Service-Level-Vereinbarungen (Berechtigungsverwaltung) mit Agentforce Service; Knowledge in den meisten Editionen mit Zusatzkosten.
- Salesforce-Hilfe, Available Feature Licenses (opens in a new tab) (auf Englisch), geprüft am 2026-10-12: Service Cloud User, «Access the Salesforce Console for Service»; Marketing User zum Erstellen und Verwalten von Kampagnen.