Steve Trucking, was ich entwerfen würde
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)
Modul 6 von 6 im Kapitel Stammdaten und Identität, Kapitel 6 des Kurses Data Architect, und das Ende von Teil 1. Zurück: Wenn die Autorität geteilt ist · Weiter: Teil 2 beginnt mit Designing for Scale (coming soon)
Die Frage, die dieser Checkpoint beantwortet: Können Sie Teil 1 an einem echten Szenario zusammensetzen?
Versuchen Sie zuerst die Herausforderung. Das ist mein Durchgang durch die Herausforderung zu Checkpoint 1. Wenn Sie Ihren eigenen Entwurf noch nicht gezeichnet haben, tun Sie das, bevor Sie weiterlesen. Der Wert liegt darin, Ihre Begründung mit meiner zu vergleichen, nicht darin, die Antwort zu lesen.
Das ist „Was ich entwerfen würde“: eine mögliche tragfähige Lösung, nicht die Antwort, mit benannten Abwägungen und bezogenen Positionen. Wir haben große Datenvolumen, Abfrageentwurf, Integrationsmuster, Migration und Transaktionen noch nicht behandelt, und das ist Absicht: Architektur entwickelt sich, wenn Sie mehr lernen. Aber Teil 1 gibt uns genug, um das Skelett zu setzen.
Beginnen Sie mit den Zahlen
Abschnitt betitelt „Beginnen Sie mit den Zahlen “Aus dem Steckbrief: etwa 3.300 Lieferungen pro Arbeitstag, eine Million im Jahr, mit 30 % Wachstum pro Jahr. Etwa 1,6 Positionen pro Lieferung (1,6 Millionen im Jahr); etwa acht Statusänderungen pro Lieferung (8 Millionen im Jahr); vier bis fünf Millionen Fotos im Jahr; etwa 200.000 GPS-Messwerte am Tag; etwa 180.000 Kundenvorgänge im Jahr; drei Handelspartner, die Ladelisten auf drei verschiedene Arten schicken; neun Verteilzentren; 330 Lkw mit Zwei-Personen-Crews. Und Steve Trucking betreibt bereits eine Salesforce-Org mit Service Cloud, Field Service und einem Partnerportal. Zählen Sie die Nullen, bevor Sie einen einzigen Kasten zeichnen. Sie werden unten mehreres entscheiden.
Der Kern der Lieferungen: Schauen Sie aufs Mutterschiff
Abschnitt betitelt „Der Kern der Lieferungen: Schauen Sie aufs Mutterschiff “Die Lieferungen sind das Herz des Ganzen, und Field Service erledigt bereits die Disposition. Also beginne ich mit dem Standardmodell von Field Service, wie es der Ausschnitt in Kapitel 3 getan hat:
| Geschäftskonzept | Salesforce-Objekt | Warum |
|---|---|---|
| Handelspartner | Account (Datensatztyp Retail Partner) | Ein Unternehmen, mit dem Steve Trucking Verträge hat; trägt Verträge, Kundenvorgänge und Portalzugang |
| Personal der Partner (Leitungen der Verteilzentren, Filialpersonal) | Contact | Portalbenutzer müssen Kontakte sein |
| Eine Lieferung: ein Empfänger, eine Adresse, ein Partnerauftrag, ein Tag | Work Order | Die Arbeitseinheit von Field Service; Planung, mobile App und Serviceberichte hängen daran |
| Jeder Artikel oder jede Leistung: der Kühlschrank, die Installation, die Mitnahme | Work Order Line Item | Teilt die Arbeit auf, steuert Checklisten und Fakturierung |
| Die Art des Stopps: nur Lieferung, mit Installation, mit Mitnahme | Work Type | Legt Dauer, Fähigkeiten und die Installations-Checkliste fest |
| Der geplante Besuch und sein Zeitfenster | Service Appointment | Was Field Service plant und die App der Crew zeigt |
| Crews und Lkw; Dispositionsgebiete der Verteilzentren | Service Resource, Service Crew, Service Territory | Field Service plant eine Crew als eine Ressource |
| Anfragen von Empfängern, Reklamationen von Partnern | Case | Die Servicekonsole, Berechtigungen, E-Mail-to-Case |
| Die Liste des Partners für Dienstag im Verteilzentrum Phoenix | Manifest__c (benutzerdefiniert) | Nichts Standardmäßiges bildet die Einheit von Empfang, Abgleich und Wiederholung ab |
Alles andere bleibt Standard. Weiteren benutzerdefinierten Objekten zu widerstehen ist Absicht: Die Frage aus Kapitel 1 war, wann man in der Architektur einem weiteren widerstehen sollte, und hier lautet die Antwort „fast immer“. Die Auftragszeile des Partners zum Beispiel ist kein neues Objekt. Sie ist der Arbeitsauftrag, identifiziert über die Referenz des Partners.
Es wächst aus dem Finale von Kapitel 3 (Das physische Salesforce-Modell entwerfen): dieselben Objekte an denselben Stellen, ergänzt um die Crew, das Dispositionsgebiet, den Kundenvorgang und das, was Checkpoint 1 außerhalb des Core hält.
Der Schlüssel, der den Auftrag eines Partners einer Lieferung zuordnet
Abschnitt betitelt „Der Schlüssel, der den Auftrag eines Partners einer Lieferung zuordnet “Jede Zeile der Ladeliste wird ein Arbeitsauftrag, verknüpft mit ihrer Ladeliste. Der Schlüssel ist die Frage, die ich am dringendsten beantwortet haben will: Woher wissen wir, dass diese Zeile des Partners jene Lieferung ist? Meine Antwort: eine externe ID auf dem Arbeitsauftrag, gebildet aus dem Handelspartner und der eigenen Auftrags- und Lieferreferenz des Partners (etwa KEYSTONE-PHX-8843119-1), als eindeutig gekennzeichnet. Ein Feld pro Quelle, eins zu eins. Es ist die Kennung des Partners, nicht unsere: „mehrere Kennungen für ein Ding“ aus Kapitel 2 und „der Partner besitzt seine Auftragsreferenz“ aus Modul 1.
Warum es zählt: Ladelisten kommen ein bis zwei Tage vorher an und werden am Tag selbst geändert. Mit diesem Schlüssel führt jede erneut gesendete oder geänderte Ladeliste einen Upsert aus, statt Duplikate zu erzeugen. Die Änderung aktualisiert den Arbeitsauftrag, ein Feld hält sie fest, und eine Änderung an einer bereits verplanten Lieferung alarmiert die Disposition: Die Änderung des Partners wird angewendet, aber markiert, bis die Disposition sie bestätigt. Das ist auch, was sich gegenüber dem Bild aus Kapitel 4 ändert. Heute landet jede Ladeliste in RouteDesk, und die Disposition tippt Touren in Salesforce ab und erledigte Stopps wieder zurück. In diesem Entwurf kommen die Ladelisten direkt in Salesforce an, per Upsert über den Schlüssel des Partners; RouteDesk wird abgelöst, und das Abtippen endet. Das Integrationskapitel entwirft die drei eingehenden Formate. Die Datenentscheidung ist der Schlüssel.
Der Empfänger: Personenaccount, Kontakt oder keins von beiden?
Abschnitt betitelt „Der Empfänger: Personenaccount, Kontakt oder keins von beiden? “Das ist die interessanteste Datenentscheidung in Teil 1, also hier die Optionen, dann meine Wahl.
Option A: Personenaccounts. Jeder Empfänger wird ein Personenaccount, verknüpft mit jeder Lieferung. Dafür: Standard, funktioniert natürlich mit Service Cloud, Messaging und der Konsole, erkennt wiederkehrende Empfänger. Dagegen: etwa eine Million neue Empfänger im Jahr, jeder ein Personenaccount mit etwa doppeltem Speicherbedarf eines Firmenaccounts (Estimated Record Size by Object Type (opens in a new tab), auf Englisch), also innerhalb von zwei Jahren eines der größten Objekte in der Org. Und Empfänger sind nicht die Kunden von Steve Trucking. Sie sind die Kunden jedes Handelspartners, und Steve Trucking darf nie den Kunden eines Partners mit dem eines anderen vermischen (S2).
Option B: Kontakte unter dem Account des Handelspartners. Dagegen: Eine Million Kontakte unter drei oder vier Accounts ist eine Eltern-Kind-Schieflage gewaltigen Ausmaßes, weit jenseits der Empfehlung von Salesforce von etwa 10.000 untergeordneten Datensätzen pro übergeordnetem (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab), beide auf Englisch). Das ist die Option, die man zeigt, und verwirft.
Option C: Der Empfänger lebt auf der Lieferung. Name, Telefon, E-Mail, Adresse und Liefernotizen des Empfängers sind Felder auf dem Arbeitsauftrag (die Adressfelder sind dort schon Standard), aus der Ladeliste übernommen. Dafür: kein neues großes Objekt; die Daten leben genau so lange, wie die Lieferung sie braucht; gelöscht wird pro Lieferung, nach dem Zeitplan des Partners; und die Trennung der Partner gibt es umsonst, weil jede Lieferung zu einem Partner gehört. Dagegen: Ein wiederkehrender Empfänger wird nicht als dieselbe Person erkannt.
Das ist die Abwägung, die es zu treffen gilt. Wird es je nötig sein, mehrere Lieferungen als dieselbe Person am selben Ort zu erkennen? Dieser Person eine Anmeldung zu geben? Das ist die Grenze zwischen einem Empfänger, der einen eigenen Datensatz braucht, und Empfängerangaben, die einfach Daten über die Lieferung sind. Und es gibt einen Mittelweg. Führen Sie die eigene Kunden-ID des Handelspartners als Feld auf der Lieferung mit, eine Retail Partner Customer ID (Kunden-ID des Handelspartners). Sie legt keinen Empfängerdatensatz an, verbindet aber die Lieferungen, die ein Partner für denselben Kunden schickt, und das ist der Anfang eines einheitlicheren Kundenerlebnisses; und sie führt direkt zurück ins System des Handelspartners, wo dieser Kunde wirklich lebt. Es ist dessen Kennung, also bedeutet sie nur zusammen mit dem Partner etwas: Der Kunde 4417 des einen Partners hat nichts mit dem eines anderen zu tun.
Nach meiner fachlichen Einschätzung ist Option C die richtige Wahl. Dass er nicht erkannt wird, ist akzeptabel, sogar wünschenswert: Steve Trucking hat mit diesen Menschen keine Beziehung über die Lieferung hinaus. Es ist wieder Modul 1: Der Empfänger ist der Kunde des Partners, und der Partner ist die Autorität dafür, wer er ist. Und es ist Kapitel 5: Personenbezogene Daten, die an einem Ort landen, verbunden mit einer Lieferung, sind weit leichter zu schützen, aufzubewahren und zu löschen. Und es hält den Normalformen aus Kapitel 2 stand: Die Angaben des Empfängers stehen eins zu eins zur Lieferung, also gehören sie auf sie. Ein eigenes untergeordnetes Empfängerobjekt würde ein paar wiederholte Werte sparen, um den Preis eines weiteren Objekts, einer weiteren Beziehung und ihres Aufwands, und mehr sparen würde es nur, wenn wir dieselbe Person über Handelspartner hinweg als eine behandelten, was wir nicht tun. Also trägt die Lieferung den Empfänger, mit der Retail Partner Customer ID als Weg zurück ins eigene System des Partners.
Würde ich Empfänger über Partner hinweg vereinheitlichen?
Abschnitt betitelt „Würde ich Empfänger über Partner hinweg vereinheitlichen? “John Smith, 123 Main Street, erscheint in der Ladeliste von Redrock und in der von Brightwave. Wahrscheinlich dieselbe Person. Sollte Steve Trucking sie vereinheitlichen? Nein, bewusst nicht. Empfänger über Handelspartner hinweg zu vereinheitlichen würde S2 verletzen: Ein Partner darf nie die Empfänger eines anderen sehen, und eine einheitliche Identität ist genau die Brücke, über die es durchsickert. Das ist die Position dieses Kapitels in der Anwendung: Gleichen Sie zu wenig ab, wo Vermischung teuer ist, und hier ist Vermischung sehr teuer.
Wenn ein Handelspartner später wiederkehrende Empfänger innerhalb seiner eigenen Lieferungen erkennen will, ist das eine Aufgabe für ein Werkzeug zur Identitätsauflösung, etwa das von Data 360, auf diesen Partner beschränkt: eine Karte im Stil einer Registry, kein Personenaccount, und nie über Partner hinweg. Eine Karte, wer wer ist, gewährt keine Eigentümerschaft und keinen Zugriff.
Was in der Org bleibt, und was nicht
Abschnitt betitelt „Was in der Org bleibt, und was nicht “Kapitel 3 hat gefragt, wo Daten liegen sollten. Hier beantworten es die Nullen:
- Der aktuelle Status lebt auf dem Serviceeinsatz und dem Arbeitsauftrag. Die Historie der Statusänderungen, etwa 8 Millionen im Jahr und wachsend, muss nicht in der Core-Org leben. Jede Änderung wird als Ereignis veröffentlicht und im Data Warehouse, Snowflake, gehalten. Die Org behält den aktuellen Zustand; die Historie ist für Service, Betrieb und Analytik weiterhin da, nur nicht in der operativen Datenbank.
- Fotos (vier bis fünf Millionen im Jahr, manche zeigen Menschen oder das Innere eines Zuhauses) leben außerhalb des Core in einem Speicher, der für dieses Volumen gebaut ist, direkt aus der App der Crew hochgeladen. Die Org behält nur, was sie braucht: einen kleinen Indexdatensatz pro Foto, oder nur eine Anzahl und ein Kennzeichen „erforderliche Installationsfotos vollständig“. Ich bevorzuge die leichtere Option: die Org schlank halten und den Fotospeicher seinen Index und seine Aufbewahrung besitzen lassen.
- GPS-Messwerte (200.000 am Tag) bleiben in FleetLink und gehen nach Snowflake; die Org braucht nur die letzte Position für die Sendungsverfolgungsseite und die Karte der Disposition.
- Die acht Jahre Historie von RouteDesk (etwa 5 Millionen Lieferungen) gehen ins Data Warehouse oder in ein Archiv, erreichbar für Reklamationen. Was, wenn überhaupt, in die Org kommt, ist eine Migrationsentscheidung für Teil 2.
Checkpoint 1: was ich entwerfen würde. Dieselben Stellen wie in der Landschaft aus Kapitel 4 (Die Landschaft von Steve Trucking), ohne das Abtippen und ohne die Tabellenkalkulation.
Wer was sieht, und wer eine Lizenz braucht
Abschnitt betitelt „Wer was sieht, und wer eine Lizenz braucht “- Handelspartner sehen nur ihre eigenen Lieferungen (S2). Jeder Arbeitsauftrag trägt seinen Handelspartner; Portalbenutzer sehen die Lieferungen ihres Partners, und Leitungen von Verteilzentren nur die ihres Zentrums.
- Partnerbenutzer brauchen eine Portallizenz, die Freigaberegeln und Rollen unterstützt: Customer Community Plus oder Partner Community. Die Stadionplätze aus Kapitel 3: Die billigsten Plätze bekommen nicht die Freigabe, die dieser Entwurf braucht. Beide Lizenzen brauchen Rollen für die externen Benutzer, und Salesforce warnt, dass mehr Rollen die Org verlangsamen (Experience Cloud User Licenses (opens in a new tab), auf Englisch). Eine Rolle pro Partner und pro Verteilzentrum ist in Ordnung; eine Rolle für jede Filiale nicht.
Prüfungswissen. Wissen Sie, welche externen Lizenzen die Standardfreigabe mitbringen: Customer Community Plus und Partner Community (mit Rollen für die externen Benutzer), nicht Customer Community, die Freigabesätze nutzt.
- Empfänger brauchen keine Lizenz. Die Sendungsverfolgungsseite zeigt eine Lieferung über einen Link mit einem ablaufenden Token (S3), keine Anmeldung.
- Achten Sie auf die Schieflage. Hunderttausende Arbeitsaufträge im Jahr, die auf drei oder vier Partner-Accounts zeigen, sind eine Datenschieflage bei Accounts. Eine Option ist ein untergeordneter Account pro Verteilzentrum unter jedem Partner, was die untergeordneten Datensätze auf neun oder mehr Wege verteilt; erledigte Lieferungen nach Ablauf der Reklamationsfrist zu archivieren hält die aktiven untergeordneten Datensätze pro übergeordnetem niedrig. Teil 2 nimmt sich das vor.
Was ich nicht tun würde
Abschnitt betitelt „Was ich nicht tun würde “Ich würde nicht für jeden Empfänger einen Personenaccount anlegen, weil ein Empfänger eine Einzelperson ist. Ich würde keine Million Kontakte an drei Accounts hängen. Ich würde kein benutzerdefiniertes Objekt Delivery neben dem Arbeitsauftrag von Field Service bauen. Ich würde Empfänger nicht über Partner hinweg vereinheitlichen. Ich würde keine Millionen Fotos oder GPS-Messwerte in den Core-Speicher legen. Und ich würde einen vereinheitlichten Empfänger nicht Golden Record nennen, solange wir nicht tatsächlich eine Stammdatenentscheidung getroffen haben.
Was noch offen ist
Abschnitt betitelt „Was noch offen ist “Teil 1 hat das Skelett gesetzt; Teil 2 prüft es. Der LDV-Maßstab im dritten Jahr (Arbeitsaufträge, Serviceeinsätze und Positionen sind innerhalb von zwei bis drei Jahren alle im Bereich großer Volumen), der Abfrageentwurf für auf Partner beschränkte Listenansichten, die drei eingehenden Integrationen und drei Statusfeeds, die Migration von RouteDesk, Transaktionen am Tag selbst und der Sicherheitsentwurf hinter dem Portal. Auch Steve Trucking wird sich ändern. Behalten Sie diesen Entwurf; Sie werden ihn wieder aufgreifen.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welche Standardobjekte den Kern tragen (hier die von Field Service) und welche benutzerdefinierten Objekte wirklich gerechtfertigt sind (hier eines).
- Der Schlüssel, der jede Auftragszeile eines Partners einer Lieferung zuordnet, und warum er dem Partner gehört.
- Was der Empfänger ist, je nach der Beziehung, die Steve Trucking tatsächlich mit ihm hat.
- Ob Identitäten vereinheitlicht werden und wo Vermischung zu teuer ist, um das Risiko einzugehen.
- Was in der Org bleibt, was außerhalb des Core lebt und von welchen Lizenzen der Entwurf abhängt.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Der Steckbrief und die Herausforderungen von Steve Trucking (auf Englisch; D1, D3, DC1).
- Salesforce-Hilfe, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) und Experience Cloud User Licenses (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (auf Englisch), wie in Kapitel 3 zitiert.