Das physische Salesforce-Modell entwerfen

🌐 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)

Mit KI erstelltes Bild

Von KI übersetzt. Noch nicht von der Community geprüft. Auf Englisch lesen

Modul 10 von 10 im Kapitel Salesforce-Datenarchitektur, Kapitel 3 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Daten konsistent halten · Weiter: der Lernleitfaden des Kapitels, dann das nächste Kapitel, Unternehmensdaten verstehen

Die Frage, die dieses Modul beantwortet: Wie verwandeln wir unser logisches Modell in eine Salesforce-Architektur?

Dieses Kapitel war ein einziges langes Argument dafür, dass die Plattform eine Form hat: Standard- und benutzerdefinierte Objekte, Orte, an denen Daten liegen können, Feldtypen, Beziehungen, Eigentümerschaft, Lizenzen, Konsistenzregeln, Speicher und Volumen. Jedes davon kann ändern, wie das logische Modell aus Kapitel 2 gebaut wird. Setzen wir es jetzt an einem Ausschnitt von Steve Trucking zusammen.

Ein Ausschnitt, nicht das ganze Unternehmen. Ein Fehler, den ich in der Architektur oft sehe, ist der Versuch, das ganze Unternehmen in einem Diagramm zu lösen. Ich möchte etwas, worüber wir nachdenken können: Ein Handelspartner schickt eine Ladeliste, Steve Trucking liefert, was darauf steht, und wir behalten, was wir über jede Lieferung brauchen. Dann treffen wir die physischen Entscheidungen eine nach der anderen. Der vollständige Entwurf ist der Checkpoint von Teil 1.

Beginnen Sie mit dem, was wir schon wissen

Kapitel 2 hat die konzeptionelle Arbeit gemacht: Handelspartner, Empfänger, Ladeliste, Lieferung, Lieferposition, die Art des Stopps, Crew, Lkw, Verteilzentrum, Fotos. Wir haben die Beziehungen benannt und gefragt, was sie bedeuten. Das wiederhole ich nicht. Die Frage ist jetzt, wie diese Konzepte auf Salesforce leben. Eine Tatsache aus dem Steckbrief zählt sofort: Steve Trucking nutzt bereits Field Service für Termine, Crews und die mobile App.

Handelspartner: Erfinden Sie keinen Account

Ein Handelspartner ist ein Unternehmen, für das Steve Trucking arbeitet. Salesforce hat bereits ein Objekt, das für Unternehmen entworfen ist: Account. Saubere Passung. Also kein Retail_Partner__c, nur weil das Geschäft „Partner“ sagt. Es ist ein Account mit dem Datensatztyp Retail Partner, um ihn von anderen Organisationen zu unterscheiden, und mit ihm kommen Verträge, Kundenvorgänge, Kontakte für die Leitungen der Verteilzentren und Portalzugang für diese Kontakte. Leichte Entscheidung. Nicht alle sind es.

Die Auftragsnummer des Partners ist nicht unsere Identität

Jeder Handelspartner schickt seine eigenen Referenzen. Der Auftrag eines Partners sieht aus wie 8843119, der eines anderen wie A-984732. Diese Nummern zählen, aber wem gehören sie? Dem Partner. Salesforce hat seine eigene Datensatz-ID, und der Partner hat die Referenz, die er verwendet, wenn er mit uns spricht. Beide können existieren; das ist „ein Ding, mehrere Kennungen“ aus Kapitel 2.

Die Referenz des Partners wird also eine externe ID, die die Integration verwendet, um Aktualisierungen zuzuordnen. Und weil zwei Partner dieselbe Nummer verwenden könnten, ist die Identität Partner plus Referenz, nicht die Referenz allein. Machen Sie die Nummer eines Partners nicht zur universellen Identität der Lieferung, nur weil sie zuerst ankam, und lassen Sie eine Integration nicht jedes Mal ein Textfeld durchsuchen, wenn sie einen Datensatz finden muss.

Lieferung: Schauen Sie aufs Mutterschiff

Hier ist es verlockend, Delivery__c zu erstellen. Das Geschäft hat „Lieferung“ gesagt, also brauchen wir ein Objekt Lieferung. Genau das sollen Sie nicht zuerst tun. Schauen Sie aufs Mutterschiff, wie wir es in Modul 2 getan haben. Was hat Salesforce bereits für Arbeit, die an einem Ort ausgeführt wird, mit einem Lebenszyklus, Positionen, Planung und einer Crew im Außendienst? Den Arbeitsauftrag (Work Order) von Field Service: Salesforce beschreibt ihn als Außendienstarbeit, die für einen Kunden ausgeführt werden soll (WorkOrder (opens in a new tab), auf Englisch). Der geplante Besuch mit seinem Zeitfenster ist der Serviceeinsatz (Service Appointment), und den plant die Disposition und zeigt die App der Crew.

Also Lieferung → Arbeitsauftrag. Nicht weil die Wörter passen; das tun sie nicht. Sondern weil das Verhalten zu der Plattformfunktion passt, für die wir schon bezahlen und die wir nutzen wollen. Ein Standardobjekt muss nicht das Vokabular des Geschäfts teilen. Es muss das Konzept richtig darstellen.

Click to enlarge

Schritt 1 von 4: das Mutterschiff. Jede Karte ist das Geschäftskonzept, mit seinem Salesforce-Objekt darunter.

Aber Standardobjekte bringen Gepäck mit

Die andere Hälfte: Der Arbeitsauftrag ist nicht kostenlos. Er bringt Field-Service-Lizenzen, eigene Beziehungen, Sicherheitsverhalten, Pflichtfelder, Automatisierung und Lebenszyklus mit, und andere Teile der Plattform erwarten, dass er sich auf eine bestimmte Weise verhält. Wir wählen ihn, weil die Passung sauber ist und wir nutzen, was um ihn herum gebaut ist. Wollte Steve Trucking nichts von Field Service und das Modell kämpfte an jeder Ecke gegen den Prozess, würde ich es überdenken. Die Architektur ist die Passung, nicht die Bezeichnung.

Lieferpositionen: Folgen Sie dem Modell

Sobald die Lieferung ein Arbeitsauftrag ist, schauen Sie sich den Rest dieses Modells an, bevor Sie etwas erfinden. Eine Arbeitsauftragsposition (Work Order Line Item) ist eine Teilaufgabe eines Arbeitsauftrags (WorkOrderLineItem (opens in a new tab), auf Englisch): der Kühlschrank, die Installation, die Mitnahme. Also Lieferposition → Arbeitsauftragsposition. Beachten Sie, dass die erste Entscheidung die zweite geformt hat. Wir wählen nicht für jede Entität für sich ein Objekt. Übernehmen Sie ein Modell, und verstehen Sie den Rest davon, bevor Sie benutzerdefinierte Strukturen darum herum bauen.

Was für ein Stopp ist das?

Bei Steve Trucking ist ein Stopp nur Lieferung, Lieferung mit Installation oder Lieferung mit Mitnahme, und jede Art hat ihre eigene Dauer, eigene Fähigkeiten der Crew und eine eigene Installations-Checkliste. In Kapitel 2 haben wir entschieden, dass das eine Entität ist, keine Bezeichnung. Field Service hat bereits eine: den Arbeitstyp (Work Type), eine Vorlage für eine Art von Arbeit, die auf Arbeitsaufträge und Positionen angewendet werden kann (WorkType (opens in a new tab), auf Englisch). Also Art des Stopps → Arbeitstyp. Wieder nicht, weil es etwas namens Arbeitstyp gibt, sondern weil Konzept und Verhalten übereinstimmen.

Click to enlarge

Schritt 2 von 4: Folgen Sie dem Modell. Positionen und Arbeitstyp kommen mit dem Arbeitsauftrag.

Ladeliste: Jetzt will ich ein benutzerdefiniertes Objekt

Gibt es ein Standardobjekt für „die Liste des Partners für Dienstag im Verteilzentrum Phoenix“? Eigentlich nicht, und ich zwänge sie nicht in ein unpassendes Objekt, nur um sagen zu können, wir seien beim Standard geblieben. Ladeliste → Manifest__c. Sie ist die Empfangseinheit: woher sie kam (eine Datei, ein API-Stapel), wann, ihr Status und ihre Summen und, wenn ein Partner sie am selben Tag erneut schickt, was verglichen wird. Jede Zeile der Ladeliste wird ein Arbeitsauftrag, der auf sie zurückverweist.

Benutzerdefiniert ist kein Versagen. Es ist das, was die Plattform uns gibt, wenn ein Konzept kein sauberes Standardzuhause hat. Der Fehler ist nicht, ein benutzerdefiniertes Objekt zu erstellen; er ist, eines zu erstellen, ohne zu prüfen, ob die Plattform das Konzept schon hat.

Click to enlarge

Schritt 3 von 4: das eine benutzerdefinierte Objekt, wo kein Standardobjekt passt.

Fotos: Nur weil Salesforce es speichern kann, heißt das nicht, dass es das sollte

„Wir brauchen die Lieferfotos in Salesforce.“ Was heißt „in Salesforce“? Die Benutzer müssen sie aus Salesforce heraus sehen, ja. Heißt das, die Bilddateien müssen im Core-Speicher liegen? Nicht unbedingt. Zählen Sie die Nullen: etwa vier Fotos pro Lieferung, mehr bei Installationen, bei einer Million Lieferungen im Jahr sind das vier bis fünf Millionen Fotos im Jahr, und die Lieferungen wachsen um 30 % pro Jahr.

Meine Ausgangsposition also: Machen Sie die Core-Org nicht zu einem riesigen Fotoarchiv, nur weil Benutzer Zugriff auf Fotos brauchen. Die Dateien gehören in einen Speicher, der für dieses Volumen gebaut ist, außerhalb des Core, und Salesforce behält, was es braucht, um sie zu finden und anzuzeigen: eine Referenz, eine Anzahl oder einen kleinen Indexdatensatz pro Foto, und ein Kennzeichen, dass die erforderlichen Installationsfotos vollständig sind. Der Zugriff auf Daten und der Ort, an dem die Daten physisch liegen, sind zwei verschiedene Fragen. Das ist Modul 4, das zurückkommt.

Felder: Machen Sie die Bedeutung sichtbar

Der Arbeitsauftrag braucht Felder: die Referenz des Partners, das Lieferzeitfenster, die tatsächliche Lieferzeit, den Status, Notizen wie „Torcode“ oder „Hund im Garten“. Ich mache daraus keinen Feldkatalog; das hat Modul 6 getan. Wenden Sie die Fragen auf jedes an: was es bedeutet, wem es gehört, ob es sich ändert, ob es eine Kennung ist, ein kontrolliertes Vokabular, gespeichert oder abgeleitet, sensibel. Die Referenz des Partners ist die externe ID, also ist ihre Eindeutigkeit Teil des Integrationsvertrags, nicht nur ein Kontrollkästchen. Die tatsächliche Lieferzeit ist ein Zeitpunkt, also Datum/Uhrzeit. Der Status steuert Verhalten, also eine kontrollierte Liste, nie Freitext. Und Liefernotizen über das Zuhause einer Person sind personenbezogene Daten, also werden sie klassifiziert. Jedes Feld führt zurück zur Bedeutung.

Beziehungen: Verbinden Sie nicht nur die Kästen

Account zu Arbeitsauftrag, Arbeitsauftrag zu seinen Positionen, Ladeliste zu Arbeitsauftrag, Arbeitstyp, der den Stopp beschreibt. Dann die Fragen aus Modul 7 für jede Linie: Kann das untergeordnete Element allein existieren, wem gehört es, wird der Zugriff geerbt, kann es umziehen, was passiert beim Löschen, wie viele untergeordnete können sich ansammeln? Jeder Arbeitsauftrag unter einer Handvoll Handelspartner-Accounts bedeutet Hunderttausende untergeordnete Datensätze pro übergeordnetem: eine Schieflagefrage, die wir in Teil 2 beantworten. Und bei den Standardbeziehungen von Field Service prüfen Sie, wie Salesforce sie bereits gebaut hat, statt anzunehmen, sie entsprächen dem, was wir entworfen hätten. Wenn Sie ein Standardmodell übernehmen, übernehmen Sie die Entscheidungen, die Salesforce darin getroffen hat. Verstehen Sie sie, bevor Sie darauf bauen.

Eigentümerschaft und der Empfänger: Lassen Sie nicht den Standard entscheiden

Zwei Entscheidungen, die uns ein Standard nur zu gern abnehmen würde.

Wem gehört eine Lieferung? Das haben wir in Modul 8 beantwortet, und es überträgt sich direkt auf den Arbeitsauftrag: Die Eigentümerschaft steuert hier niemandes Zugriff, also gehören dem Integrationsbenutzer die Arbeitsaufträge, die er erstellt. Die Disposition sieht die ihres Verteilzentrums, die Crews die ihrer Touren, und jeder Handelspartner sieht seine eigenen über das Portal, alles über die Freigabe, nicht über die Eigentümerschaft. Der Integrationsbenutzer hat keine Rolle und bleibt aus den öffentlichen Gruppen heraus, die unsere Freigaberegeln verwenden, denn bei 3.300 am Tag überschreitet er in drei Tagen 10.000 Datensätze. Und wir schreiben auf, was passiert, falls dieser Benutzer je ersetzt wird.

Was ist der Empfänger? Ein Kontakt? Ein Personenaccount? Etwas, das nur auf der Lieferung gespeichert wird? Das hängt davon ab, ob Steve Trucking überhaupt eine Beziehung zu diesen Menschen hat (sie sind die Kundschaft der Handelspartner), ob ein Partner je die eines anderen sehen darf, wie lange ihre personenbezogenen Daten aufbewahrt werden dürfen, und vom Volumen: etwa eine Million neue Empfänger:innen im Jahr. All das haben wir noch nicht, und das ist in Ordnung. Manchmal lautet die richtige Antwort Wir wissen noch nicht genug. Schreiben Sie die Frage auf und beschaffen Sie die Informationen; vergraben Sie die Unsicherheit nicht in einem benutzerdefinierten Objekt. Wir beantworten sie beim Checkpoint von Teil 1, nachdem uns die Kapitel 4 bis 6 das Bild des Unternehmens und der Stammdaten gegeben haben.

Konsistenz: Schützen Sie das Modell auf der richtigen Schicht

Die Leiter aus Modul 9 gilt: Die Referenz des Partners ist eine externe ID, eindeutig, sodass eine erneut gesendete Ladeliste einen Upsert auslöst, statt zu duplizieren; der Status ist eine eingeschränkte Liste; die tatsächliche Lieferzeit ist erst erforderlich, wenn der Status Geliefert lautet; ein Installationsstopp kann ohne seine Checkliste und Fotos nicht abgeschlossen werden. Nicht ein riesiger Flow. Jede Regel auf ihrer eigenen Sprosse.

Wo jedes Teil liegt

Noch ein Durchgang durch den Ausschnitt, mit der Frage aus Modul 4: Wo liegt jedes Datenelement? In meinem Kursfoliensatz ist das eine Folie, logisch gegen physisch: die logischen Entitäten aus Kapitel 2 und wo jede physisch landet: auf dem Core, als sObject (__c, wenn es benutzerdefiniert ist) oder als Big Object (__b), oder außerhalb des Core, als externes Objekt (__x) oder als Daten, die nie nach Salesforce kommen.

• Auf dem Core, täglich bearbeitet: der Account, die Arbeitsaufträge und ihre Positionen, die Serviceeinsätze, die Arbeitstypen, Manifest__c.
• Auf dem Core, archiviert: Lieferungen, die älter als drei Jahre sind, wandern in den Lieferverlauf (Delivery History), ein Big Object, für Reklamationen weiterhin da, draußen im Schuppen.
• Referenziert: Die eigenen Auftragsdetails des Handelspartners bleiben im System des Partners; wir behalten die Referenz des Partners als externe ID und erreichen den Rest über ein externes Objekt oder die Integration, wenn jemand ihn braucht.
• Außerhalb des Core: die Fotos, in einem Speicher, der für Millionen von Bildern gebaut ist, mit einem Link vom Arbeitsauftrag.

Das ist das physische Modell: nicht nur welches Objekt, sondern welches Zuhause.

Jetzt betrachten Sie den ganzen Ausschnitt

• Handelspartner → Account mit dem Datensatztyp Retail Partner; Leitungen der Verteilzentren als Kontakte.
• Lieferung → Field-Service-Arbeitsauftrag, geplant über einen Serviceeinsatz.
• Lieferposition → Arbeitsauftragsposition.
• Art des Stopps → Arbeitstyp.
• Ladeliste → benutzerdefiniertes Manifest__c.
• Referenz des Partners → externe ID auf dem Arbeitsauftrag, eindeutig pro Partner.
• Fotos → außerhalb des Core gespeichert; Salesforce behält die Referenz und das Vollständigkeitskennzeichen.
• Lieferverlauf → nach drei Jahren in ein Big Object archiviert.
• Eigentümerschaft → der Integrationsbenutzer, mit Zugriff über die Freigabe (Modul 8).
• Empfänger → offen, für den Checkpoint von Teil 1.

Click to enlarge

Schritt 4 von 4: der ganze Ausschnitt, auf dem Core, archiviert und außerhalb des Core. Jede Linie ist eine Nachschlagebeziehung: Salesforce hat Field Service auf Nachschlagebeziehungen gebaut, und wir übernehmen seine Entscheidungen mit.

Das Diagramm ist nicht die Architektur

Ich kann Ihnen dieses Diagramm geben, und es reicht nicht. Die Architektur ist die Begründung dahinter. Warum Account? Ein sauber passendes Unternehmen. Warum Arbeitsauftrag und nicht Delivery__c? Die Lieferung verhält sich wie Außendienstarbeit, und Field Service ist schon da. Warum eine benutzerdefinierte Ladeliste? Kein sauberes Standardzuhause. Warum sind Fotos nicht einfach Dateien? Volumen und Speicherkosten. Warum eine externe ID? Ein anderes System braucht eine stabile Identität über die Grenze hinweg. Warum gehören dem Integrationsbenutzer die Arbeitsaufträge? Die Eigentümerschaft steuert hier nicht den Zugriff, und so bleibt der Prüfpfad ehrlich. Warum ist der Empfänger noch offen? Wir haben noch nicht genug Fragen beantwortet. Die Linien sind das Ergebnis; die Entscheidungen haben sie hervorgebracht.

Hier also die Gewohnheit, mit der Sie Kapitel 3 verlassen sollen. Zeigen Sie auf irgendetwas in einem physischen Modell und fragen Sie: Warum? Warum dieses Objekt, dieser Typ, diese Beziehung, dieser Eigentümer, dieser Ort, diese Regel? Sie sollten die Antwort zurückverfolgen können: von der Konfiguration zum physischen Modell, zum logischen Modell, zur geschäftlichen Anforderung. Wenn Sie das nicht können, hat jemand aus dem Setup heraus entworfen.

Und Sie haben bemerkt, welche Zahlen wir noch nicht vollständig durchgerechnet haben: Lieferungen pro Partner, Positionen, Fotos, Aufbewahrung, Archivierung. Gut. Fragen Sie nach der Anzahl der Nullen, bevor Sie einen Entwurf festschreiben: Ein Modell, das bei fünfzigtausend Datensätzen wunderbar funktioniert, kann sich bei fünfhundert Millionen ganz anders verhalten. Das ist Teil 2.

Über die Prüfung hinaus: Was KI ändert. Geben Sie einer KI den Steckbrief von Steve Trucking, und sie erzeugt in Sekunden ein Schema: Account, Arbeitsauftrag, benutzerdefinierte Objekte, Felder, sogar Deployment-Metadaten. Das ist ein fantastischer Beschleuniger, und es ist nicht die Prüfung. Die Aufgabe der Architektur verschiebt sich dahin, die Zuordnungen und ihre Folgen zu prüfen: Passung, Lizenzen, Eigentümerschaft, Lebenszyklus, Volumen, Identität, Sicherheit und was außerhalb der Plattform bleibt. KI ist die Trägerrakete; sie sagt Ihnen nicht, ob Sie in die richtige Richtung zeigen.

Was Architekt:innen hier entscheiden

• Wie jedes Geschäftskonzept auf Salesforce abgebildet wird: ein Standardobjekt, ein benutzerdefiniertes Objekt oder etwas außerhalb des Core.
• Welche Kennungen, Felder und Beziehungen die geschäftliche Bedeutung umsetzen, ohne sie stillschweigend zu ändern.
• Welches Plattformverhalten und welche Lizenzen mit einem übernommenen Standardmodell kommen.
• Welche Entscheidungen zu Eigentümerschaft, Lebenszyklus, Konsistenz, Speicher und Volumen getroffen werden müssen, bevor der Entwurf vollständig ist.
• Welche Fragen ausdrücklich offen bleiben, statt hinter einer willkürlichen Umsetzungsentscheidung versteckt zu werden.

Zu Beginn dieses Kapitels haben wir gefragt, wie das Modell auf Salesforce leben soll. Das ist Salesforce-Datenarchitektur: nicht Objekte erstellen, nicht das Setup auswendig lernen, nicht hübschere Kästen zeichnen, sondern das Geschäftsmodell bewusst an die Form der Plattform anpassen. Jede Struktur ist eine Verpflichtung. Gehen Sie die ein, die Sie erklären können.

Weiterlesen

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) und WorkType (opens in a new tab) (auf Englisch), geprüft am 2026-10-02.
• Der Steckbrief von Steve Trucking (auf Englisch).