Steve Trucking, hoe ik het zou ontwerpen
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 6 van 6 in het hoofdstuk Stamgegevens en identiteit, hoofdstuk 6 van de cursus Data Architect, en het einde van Deel 1. Vorige: Als zeggenschap gedeeld is · Volgende: Deel 2 begint met Ontwerpen voor schaal (coming soon)
De vraag die deze checkpoint beantwoordt: Kun je Deel 1 samenbrengen in een echt scenario?
Probeer eerst de opdracht. Dit is mijn uitwerking van de opdracht van Checkpoint 1. Als je je eigen ontwerp nog niet getekend hebt, doe dat dan voordat je verder leest. De waarde zit in het vergelijken van jouw redenering met de mijne, niet in het lezen van het antwoord.
Dit is “hoe ik het zou ontwerpen”: een mogelijke werkbare oplossing, niet het antwoord, met de afwegingen benoemd en mijn standpunten ingenomen. We hebben grote datavolumes, queryontwerp, integratiepatronen, migratie of transacties nog niet behandeld, en dat is bewust: architectuur ontwikkelt zich naarmate je meer leert. Maar Deel 1 geeft ons genoeg om het skelet neer te zetten.
Begin bij de getallen
Section titled “Begin bij de getallen ”Uit de briefing: ongeveer 3.300 leveringen per werkdag, een miljoen per jaar, met 30% groei per jaar. Ongeveer 1,6 regels per levering (1,6 miljoen per jaar); ongeveer acht statuswijzigingen per levering (8 miljoen per jaar); vier tot vijf miljoen foto’s per jaar; ongeveer 200.000 gps-metingen per dag; ongeveer 180.000 cases per jaar; drie retailpartners die vrachtlijsten op drie verschillende manieren sturen; negen distributiecentra; 330 vrachtwagens met tweemansploegen. En Steve Trucking draait al één Salesforce-org met Service Cloud, Field Service en een partnerportaal. Tel de nullen voordat je ook maar één vakje tekent. Ze beslissen hieronder meerdere dingen.
De kern van de leveringen: kijk naar het moederschip
Section titled “De kern van de leveringen: kijk naar het moederschip ”De leveringen zijn het hart ervan, en Field Service doet al de planning. Dus begin ik met het standaardmodel van Field Service, zoals het stuk in hoofdstuk 3 deed:
| Bedrijfsbegrip | Salesforce-object | Waarom |
|---|---|---|
| Retailpartner | Account (recordtype Retailpartner) | Een bedrijf waarmee Steve Trucking een contract heeft; draagt contracten, cases en portaaltoegang |
| Medewerkers van de partner (DC-managers, winkelpersoneel) | Contactpersoon (Contact) | Portaalgebruikers moeten contactpersonen zijn |
| Eén levering: één ontvanger, één adres, één partnerorder, één dag | Werkorder (Work Order) | De werkeenheid van Field Service; planning, de mobiele app en servicerapporten hangen eraan |
| Elk artikel of elke dienst: de koelkast, de installatie, de afvoer | Werkorderregel (Work Order Line Item) | Verdeelt het werk, stuurt checklists en facturatie |
| Het soort stop: alleen levering, met installatie, met afvoer | Werktype (Work Type) | Bepaalt duur, vaardigheden en de installatiechecklist |
| Het geplande bezoek en zijn tijdvenster | Serviceafspraak (Service Appointment) | Wat Field Service plant en de app van de ploeg toont |
| Ploegen en vrachtwagens; planningsgebieden van de distributiecentra | Service Resource, Service Crew, Service Territory | Field Service plant een ploeg als één resource |
| Vragen van ontvangers, claims van partners | Case | De serviceconsole, entitlements, email-to-case |
| De lijst van de partner voor dinsdag in het distributiecentrum Phoenix | Manifest__c (aangepast) | Niets standaards vertegenwoordigt de eenheid van ontvangst, afstemming en opnieuw afspelen |
Al het andere blijft standaard. Me verzetten tegen meer aangepaste objecten is bewust: de vraag van hoofdstuk 1 was wanneer een architect zich moet verzetten tegen nog een object, en hier is het antwoord “bijna altijd”. De orderregel van de partner is bijvoorbeeld geen nieuw object. Het is de werkorder, herkend aan de referentie van de partner.
Het groeit uit de finale van hoofdstuk 3 (Ontwerp het fysieke Salesforce-model): dezelfde objecten op dezelfde plekken, met de ploeg, het planningsgebied, de case en wat Checkpoint 1 buiten de core houdt erbij.
De sleutel die een partnerorder aan een levering koppelt
Section titled “De sleutel die een partnerorder aan een levering koppelt ”Elke regel van een vrachtlijst wordt één werkorder, gekoppeld aan zijn vrachtlijst. De sleutel is de vraag waarop ik het liefst een antwoord wil: hoe weten we dat deze regel van de partner die levering is? Mijn antwoord: een externe ID op de werkorder, opgebouwd uit de retailpartner en de eigen order- en leveringsreferentie van de partner (iets als KEYSTONE-PHX-8843119-1), gemarkeerd als uniek. Eén veld per bron, één op één. Het is de identificator van de partner, niet die van ons: “meerdere identificatoren voor één ding” uit hoofdstuk 2, en “de partner is eigenaar van zijn orderreferentie” uit module 1.
Waarom het ertoe doet: vrachtlijsten komen één tot twee dagen vooraf binnen en worden op de dag zelf herzien. Met die sleutel upsert elke opnieuw verstuurde of herziene vrachtlijst in plaats van duplicaten te maken. De herziening werkt de werkorder bij, een veld legt haar vast, en een wijziging aan een levering die al gerouteerd is, waarschuwt de coördinator: de wijziging van de partner wordt doorgevoerd, maar gemarkeerd tot de planning haar bevestigt. Dit is ook wat er verandert ten opzichte van de tekening uit hoofdstuk 4. Vandaag komt elke vrachtlijst in RouteDesk terecht, en typen coördinatoren routes over in Salesforce en voltooide stops terug. In dit ontwerp komen de vrachtlijsten rechtstreeks in Salesforce binnen, ge-upsert op de sleutel van de partner; RouteDesk wordt uitgefaseerd, en het overtypen stopt. Het hoofdstuk over integratie ontwerpt de drie inkomende formaten. De databeslissing is de sleutel.
De ontvanger: persoonsaccount, contactpersoon, of geen van beide?
Section titled “De ontvanger: persoonsaccount, contactpersoon, of geen van beide? ”Dit is de interessantste databeslissing van Deel 1, dus hier zijn de opties, en dan mijn keuze.
Optie A: persoonsaccounts. Elke ontvanger wordt een persoonsaccount, gekoppeld aan elke levering. Voor: standaard, werkt vanzelf met Service Cloud, messaging en de console, herkent terugkerende ontvangers. Tegen: ongeveer een miljoen nieuwe ontvangers per jaar, elk een persoonsaccount met ongeveer twee keer de opslag van een zakelijk account (Estimated Record Size by Object Type (opens in a new tab)), dus binnen twee jaar een van de grootste objecten in de org. En ontvangers zijn niet de klanten van Steve Trucking. Het zijn de klanten van elke retailpartner, en Steve Trucking mag de klant van de ene partner nooit vermengen met die van een andere (S2).
Optie B: contactpersonen onder het account van de retailpartner. Tegen: een miljoen contactpersonen onder drie of vier accounts is parent-child skew op enorme schaal, ver voorbij de richtlijn van Salesforce van ongeveer 10.000 children per parent (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Dit is de optie om te laten zien, en af te wijzen.
Optie C: de ontvanger staat op de levering. De naam, telefoon, e-mail, het adres en de leveringsnotities van de ontvanger zijn velden op de werkorder (de adresvelden zijn daar al standaard), overgenomen uit de vrachtlijst. Voor: geen nieuw groot object; de data leeft precies zo lang als de levering haar nodig heeft; verwijderen gebeurt per levering, volgens het schema van de partner; en de isolatie tussen partners krijg je gratis, omdat elke levering bij één partner hoort. Tegen: een terugkerende ontvanger wordt niet als dezelfde persoon herkend.
Dat is het evenwicht dat je moet vinden. Zal het ooit nodig zijn om meerdere leveringen te herkennen als dezelfde persoon, op dezelfde plek? Om die persoon een login te geven? Dat is de grens tussen een ontvanger die een eigen record nodig heeft en ontvangergegevens die gewoon data over de levering zijn. En er is een middenweg. Neem de eigen klant-ID van de retailpartner mee als veld op de levering, een klant-ID van de retailpartner (Retail Partner Customer ID). Het maakt geen ontvangerrecord aan, maar het verbindt de leveringen die een partner voor dezelfde klant stuurt, en dat is het begin van een meer geünificeerde klantervaring, en het leidt rechtstreeks terug naar het systeem van de retailpartner, waar die klant echt leeft. Het is hun identificatie, dus het betekent alleen iets samen met de partner: klant 4417 van de ene partner heeft niets te maken met die van een andere.
Naar mijn professionele mening is optie C de juiste keuze. Het niet-herkennen is acceptabel, zelfs wenselijk: Steve Trucking heeft met deze mensen geen relatie buiten de levering. Het is weer module 1: de ontvanger is de klant van de partner, en de partner heeft de zeggenschap over wie ze zijn. En het is hoofdstuk 5: persoonsgegevens die op één plek terechtkomen, verbonden met één levering, zijn veel makkelijker te beschermen, te bewaren en te verwijderen. En het houdt stand tegenover de normaalvormen uit hoofdstuk 2: de gegevens van de ontvanger zijn één-op-één met de levering, dus ze horen erop. Een apart onderliggend ontvangerobject zou een paar herhaalde waarden besparen ten koste van nog een object, nog een relatie en de overhead ervan, en de enige manier waarop het meer zou besparen, is door dezelfde persoon over retailpartners heen als één te behandelen, en dat doen we niet. Dus de levering draagt de ontvanger, met de klant-ID van de retailpartner als weg terug naar het eigen systeem van de partner.
Zou ik ontvangers over partners heen unificeren?
Section titled “Zou ik ontvangers over partners heen unificeren? ”John Smith, 123 Main Street, staat in de vrachtlijst van Redrock en in die van Brightwave. Waarschijnlijk dezelfde persoon. Moet Steve Trucking ze unificeren? Nee, bewust niet. Ontvangers over retailpartners heen unificeren zou S2 schenden: een partner mag nooit de ontvangers van een andere partner zien, en een geünificeerde identiteit is precies de brug waarlangs het lekt. Het is het standpunt van dit hoofdstuk, toegepast: match te weinig waar vermengen duur is, en hier is vermengen heel duur.
Als een retailpartner later terugkerende ontvangers binnen zijn eigen leveringen wil herkennen, is dat een taak voor een tool voor identiteitsresolutie, zoals die van Data 360, afgebakend tot die partner: een kaart in registrystijl, geen persoonsaccount, en nooit over partners heen. Een kaart van wie wie is, geeft geen eigenaarschap, en ook geen toegang.
Wat in de org blijft, en wat niet
Section titled “Wat in de org blijft, en wat niet ”Hoofdstuk 3 vroeg waar data hoort te staan. De nullen beantwoorden het hier:
- De huidige status staat op de serviceafspraak en de werkorder. De historie van statuswijzigingen, ongeveer 8 miljoen per jaar en groeiend, hoeft niet in de core-org te staan. Elke wijziging wordt gepubliceerd als event en bewaard in het datawarehouse, Snowflake. De org houdt de huidige toestand bij; de historie is er nog steeds voor service, operations en analytics, alleen niet in de operationele database.
- Foto’s (vier tot vijf miljoen per jaar, sommige met mensen of de binnenkant van een huis) staan buiten de core in opslag die voor dat volume gebouwd is, rechtstreeks geüpload vanuit de app van de ploeg. De org houdt alleen bij wat ze nodig heeft: een klein indexrecord per foto, of alleen een aantal en een markering “verplichte installatiefoto’s compleet”. Mijn voorkeur is de lichtere optie: houd de org slank, en laat de fotoopslag eigenaar zijn van haar index en bewaartermijn.
- Gps-metingen (200.000 per dag) blijven in FleetLink en gaan naar Snowflake; de org heeft alleen de laatste positie nodig voor de trackingpagina en de kaart van de planner.
- De acht jaar historie van RouteDesk (ongeveer 5 miljoen leveringen) gaan naar het datawarehouse of een archief, bereikbaar voor claims. Wat er eventueel in de org komt, is een migratiebeslissing voor Deel 2.
Checkpoint 1: hoe ik het zou ontwerpen. Dezelfde plekken als het landschap uit hoofdstuk 4 (Het landschap van Steve Trucking), zonder het overtypen en de spreadsheet.
Wie ziet wat, en wie heeft een licentie nodig
Section titled “Wie ziet wat, en wie heeft een licentie nodig ”- Retailpartners zien alleen hun eigen leveringen (S2). Elke werkorder draagt zijn retailpartner; portaalgebruikers zien de leveringen van hun partner, en DC-managers alleen die van hun distributiecentrum.
- Partnergebruikers hebben een portaallicentie nodig die deelregels en rollen ondersteunt: Customer Community Plus of Partner Community. De stadionplaatsen uit hoofdstuk 3: de goedkoopste plaatsen krijgen niet de sharing die dit ontwerp nodig heeft. Beide licenties hebben rollen nodig voor de externe gebruikers, en Salesforce waarschuwt dat meer rollen de org vertragen (Experience Cloud User Licenses (opens in a new tab)). Een rol per partner en per distributiecentrum is prima; een rol voor elke winkel niet.
Examenkennis. Weet welke externe licenties standaard delen (standard sharing) meebrengen: Customer Community Plus en Partner Community (met rollen voor de externe gebruikers), niet Customer Community, dat sharing sets gebruikt.
- Ontvangers hebben geen licentie nodig. De trackingpagina toont één levering via een link met een token dat verloopt (S3), geen login.
- Let op de skew. Honderdduizenden werkorders per jaar die naar drie of vier partneraccounts wijzen, zijn account data skew. Eén optie is een child-account per distributiecentrum onder elke partner, wat de children over negen of meer parents verdeelt; afgeronde leveringen archiveren na de claimperiode houdt het aantal actieve children per parent laag. Deel 2 gaat daarop in.
Wat ik niet zou doen
Section titled “Wat ik niet zou doen ”Ik zou geen persoonsaccount aanmaken voor elke ontvanger omdat een ontvanger een individu is. Ik zou geen miljoen contactpersonen aan drie accounts hangen. Ik zou geen aangepast object Delivery bouwen naast de werkorder van Field Service. Ik zou ontvangers niet over partners heen unificeren. Ik zou geen miljoenen foto’s of gps-metingen in de core-opslag zetten. En ik zou een geünificeerde ontvanger geen golden record noemen, tenzij we echt een beheerbeslissing genomen hadden.
Wat nog openstaat
Section titled “Wat nog openstaat ”Deel 1 zette het skelet neer; Deel 2 test het. De LDV-meetlat in jaar drie (werkorders, serviceafspraken en regels zitten binnen twee tot drie jaar allemaal in het gebied van grote volumes), queryontwerp voor lijstweergaven per partner, de drie inkomende integraties en drie statusfeeds, de migratie van RouteDesk, transacties op de dag zelf, en het beveiligingsontwerp achter het portaal. Steve Trucking zal ook veranderen. Bewaar dit ontwerp; je komt erop terug.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Welke standaardobjecten de kern dragen (hier die van Field Service), en welke aangepaste objecten echt gerechtvaardigd zijn (hier één).
- De sleutel die de orderregel van elke partner aan een levering koppelt, en waarom hij bij de partner hoort.
- Wat de ontvanger is, op basis van de relatie die Steve Trucking echt met hem heeft.
- Of je identiteiten unificeert, en waar vermengen te duur is om te riskeren.
- Wat in de org blijft, wat buiten de core staat, en van welke licenties het ontwerp afhangt.
Verder lezen
Section titled “Verder lezen ”- De briefing en uitdagingen van Steve Trucking (D1, D3, DC1).
- Salesforce Help, Salesforce Data Storage: Estimated Record Size by Object Type (opens in a new tab), Considerations for Object Relationships (opens in a new tab) en Experience Cloud User Licenses (opens in a new tab) (Engels, gecontroleerd op 2026-10-14).
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (Engels), zoals geciteerd in hoofdstuk 3.