Steve Trucking, sådan ville jeg designe det

🌐 Findes også på 28 sprog

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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Billedet er lavet med AI

Oversat med AI. Fællesskabet har endnu ikke gennemgået oversættelsen. Læs på engelsk

Modul 6 af 6 i kapitlet Masterdata og identitet, kapitel 6 i kurset Data Architect, og afslutningen på del 1. Forrige: Når autoriteten er delt · Næste: Del 2 begynder med Design til skala (coming soon)

Spørgsmålet, dette kontrolpunkt besvarer: Kan du samle del 1 på et rigtigt scenarie?

Prøv opgaven først. Dette er min gennemgang af opgaven til kontrolpunkt 1. Hvis du ikke har tegnet dit eget design endnu, så gør det, før du læser videre. Værdien ligger i at sammenligne din argumentation med min, ikke i at læse svaret.

Dette er »Sådan ville jeg designe det«: en mulig, holdbar løsning, ikke det rigtige svar, med afvejningerne navngivet og mine holdninger klart udtrykt. Vi har ikke gennemgået store datamængder, forespørgselsdesign, integrationsmønstre, migrering eller transaktioner endnu, og det er med vilje: Arkitektur udvikler sig, efterhånden som du lærer mere. Men del 1 giver os nok til at sætte skelettet.

Start med tallene

Fra briefen: omkring 3.300 leveringer pr. arbejdsdag, en million om året, med en vækst på 30 % om året. Omkring 1,6 linjer pr. levering (1,6 millioner om året); omkring otte statusændringer pr. levering (8 millioner om året); fire til fem millioner fotos om året; omkring 200.000 GPS-målinger om dagen; omkring 180.000 sager om året; tre detailpartnere, der sender manifester på tre forskellige måder; ni distributionscentre; 330 lastbiler med teams på to personer. Og Steve Trucking kører allerede én Salesforce-org med Service Cloud, Field Service og en partnerportal. Tæl nullerne, før du tegner en eneste boks. De kommer til at afgøre flere ting nedenfor.

Leveringskernen: kig på moderskibet

Leveringerne er hjertet i det hele, og Field Service håndterer allerede dispatch. Så jeg starter med standardmodellen i Field Service, ligesom udsnittet i kapitel 3 gjorde:

Forretningsbegreb	Salesforce-objekt	Hvorfor
Detailpartner (Retail Partner)	Account (posttypen Retail Partner)	En virksomhed, Steve Trucking har kontrakt med; bærer kontrakter, sager og portaladgang
Partnerens medarbejdere (DC-ledere, butikspersonale)	Contact	Portalbrugere skal være kontakter
Én levering: én modtager, én adresse, én partnerordre, én dag	Work Order	Field Services arbejdsenhed; planlægning, mobilappen og servicerapporter hænger på den
Hver vare eller ydelse: køleskabet, monteringen, bortskaffelsen	Work Order Line Item	Deler arbejdet op, styrer tjeklister og fakturering
Typen af stop: kun levering, med montering, med bortskaffelse	Work Type	Fastsætter varighed, færdigheder og monteringstjeklisten
Det planlagte besøg og dets tidsvindue	Service Appointment	Det, Field Service planlægger, og teamets app viser
Teams og lastbiler; DC’ernes dispatch-områder	Service Resource, Service Crew, Service Territory	Field Service planlægger et team som én ressource
Henvendelser fra modtagere, reklamationer fra partnere	Case	Servicekonsollen, serviceaftaler (entitlements), email-to-case
Partnerens liste for tirsdag i DC’et i Phoenix	Manifest__c (brugerdefineret)	Intet standardobjekt repræsenterer enheden for modtagelse, afstemning og genafspilning

Alt andet forbliver standard. Det er bevidst, at jeg modstår flere brugerdefinerede objekter: Kapitel 1 spurgte, hvornår en arkitekt bør modstå endnu et, og her er svaret »næsten altid«. Partnerens ordrelinje er for eksempel ikke et nyt objekt. Den er arbejdsordren (Work Order), identificeret ved partnerens reference.

Click to enlarge

Den vokser ud af finalen i kapitel 3 (Design den fysiske model i Salesforce): de samme objekter på de samme pladser, med teamet, dispatch-området, sagen og det, kontrolpunkt 1 holder uden for core, tilføjet.

Nøglen, der matcher en partners ordre med en levering

Hver manifestlinje bliver til én arbejdsordre, linket til sit manifest. Nøglen er det spørgsmål, jeg allerhelst vil have besvaret: Hvordan ved vi, at denne linje fra partneren er den levering? Mit svar: et External ID på arbejdsordren, bygget af detailpartneren og partnerens egen ordre- og leveringsreference (noget i stil med KEYSTONE-PHX-8843119-1), markeret som unikt. Ét felt pr. kilde, én-til-én. Det er partnerens identifikator, ikke vores: »flere identifikatorer for én ting« fra kapitel 2 og »partneren ejer sin ordrereference« fra modul 1.

Hvorfor det betyder noget: Manifester ankommer en til to dage i forvejen og bliver ændret på selve dagen. Med den nøgle laver hvert gensendt eller ændret manifest upsert i stedet for at skabe dubletter. Ændringen opdaterer arbejdsordren, et felt registrerer den, og en ændring af en levering, der allerede er ruteplanlagt, advarer koordinatoren: Partnerens ændring bliver anvendt, men markeret, indtil dispatch bekræfter den. Det er også det, der ændrer sig i forhold til billedet i kapitel 4. I dag lander hvert manifest i RouteDesk, og koordinatorerne indtaster ruterne igen i Salesforce og de afsluttede stop tilbage. I dette design kommer manifesterne direkte ind i Salesforce med upsert på partnerens nøgle; RouteDesk udfases, og den dobbelte indtastning slutter. Kapitlet om integration designer de tre indgående formater. Databeslutningen er nøglen.

Modtageren: personkonto, kontakt eller ingen af delene?

Det her er den mest interessante databeslutning i del 1, så her er mulighederne og derefter mit valg.

Mulighed A: personkonti. Hver modtager bliver en personkonto, linket til hver levering. For: standard, fungerer naturligt med Service Cloud, beskeder og konsollen, genkender modtagere, der går igen. Imod: omkring en million nye modtagere om året, hver en personkonto med cirka dobbelt så meget lagerplads som en erhvervskonto (Estimated Record Size by Object Type (opens in a new tab), på engelsk), så inden for to år et af de største objekter i org’en. Og modtagerne er ikke Steve Truckings kunder. De er hver detailpartners kunder, og Steve Trucking må aldrig blande én partners kunde sammen med en andens (S2).

Mulighed B: kontakter under detailpartnerens konto. Imod: en million kontakter under tre eller fire konti er forælder-barn-skew i massiv skala, langt over Salesforces vejledning på omkring 10.000 børn pr. forælder (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab); på engelsk). Det er muligheden, man skal vise og afvise.

Mulighed C: Modtageren lever på leveringen. Modtagerens navn, telefon, e-mail, adresse og leveringsnoter er felter på arbejdsordren (adressefelterne er allerede standard dér), hentet fra manifestet. For: intet nyt stort objekt; dataene lever præcis så længe, leveringen har brug for dem; sletning sker pr. levering, efter partnerens tidsplan; og adskillelsen mellem partnere kommer gratis, fordi hver levering tilhører én partner. Imod: En modtager, der går igen, bliver ikke genkendt som den samme person.

Det er den balance, der skal findes. Bliver der nogensinde brug for at genkende flere leveringer som den samme person, på det samme sted? For at give den person et login? Det er grænsen mellem en modtager, der har brug for sin egen post, og modtageroplysninger, der simpelthen er data om leveringen. Og der findes en mellemvej. Tag detailpartnerens eget kunde-id med som et felt på leveringen, et Retail Partner Customer ID (detailpartnerens kunde-id). Det opretter ikke en modtagerpost, men det binder de leveringer sammen, som en partner sender til den samme kunde, hvilket er begyndelsen på en mere samlet kundeoplevelse, og det fører direkte tilbage til detailpartnerens system, hvor kunden reelt bor. Det er partnerens identifikator, så det betyder kun noget sammen med partneren: Én partners kunde 4417 har intet at gøre med en andens.

Efter min faglige vurdering er mulighed C det rigtige valg. Den del med, at modtageren ikke genkendes, er acceptabel, endda ønskelig: Steve Trucking har ingen relation til de mennesker ud over leveringen. Det er modul 1 igen: Modtageren er partnerens kunde, og partneren er autoriteten for, hvem de er. Og det er kapitel 5: Personoplysninger, der lander ét sted, bundet til én levering, er langt lettere at beskytte, opbevare og slette. Og det holder over for normalformerne fra kapitel 2: Modtagerens oplysninger er én-til-én med leveringen, så de hører hjemme på den. Et separat underordnet modtagerobjekt ville spare nogle få gentagne værdier for prisen af endnu et objekt, endnu en relation og dens omkostninger, og den eneste måde, det ville spare mere på, er ved at behandle den samme person som én på tværs af detailpartnere, og det gør vi ikke. Så leveringen bærer modtageren, med Retail Partner Customer ID som vejen tilbage til partnerens eget system.

Click to enlarge

Ville jeg samle modtagere på tværs af partnere?

John Smith, 123 Main Street, optræder i Redrocks manifest og i Brightwaves. Sandsynligvis den samme person. Skal Steve Trucking samle dem? Nej, bevidst ikke. At samle modtagere på tværs af detailpartnere ville bryde S2: En partner må aldrig se en anden partners modtagere, og en samlet identitet er netop den bro, der lækker. Det er kapitlets holdning anvendt: Undermatch, hvor det er dyrt at blande sammen, og her er det meget dyrt.

Hvis en detailpartner senere vil have genkendelse af modtagere, der går igen, inden for sine egne leveringer, er det en opgave for et værktøj til identitetsopløsning, som det i Data 360, afgrænset til den partner: et kort i registerstil, ikke en personkonto, og aldrig på tværs af partnere. Et kort over, hvem der er hvem, giver ikke ejerskab, og det giver ikke adgang.

Hvad der bliver i org’en, og hvad der ikke gør

Kapitel 3 spurgte, hvor data skal bo. Nullerne svarer her:

• Aktuel status bor på serviceaftalen (Service Appointment) og arbejdsordren. Historikken over statusændringer, omkring 8 millioner om året og stigende, behøver ikke bo i core-org’en. Hver ændring publiceres som en hændelse og gemmes i datavarehuset, Snowflake. Org’en beholder den aktuelle tilstand; historikken er der stadig til service, drift og analyse, bare ikke i den operationelle database.
• Fotos (fire til fem millioner om året, nogle af dem med mennesker eller indersiden af et hjem) bor uden for core i et lager bygget til den volumen, uploadet direkte fra teamets app. Org’en beholder kun det, den har brug for: en lille indekspost pr. foto eller bare et antal og et flag for »påkrævede monteringsfotos er komplette«. Jeg foretrækker den lette løsning: Hold org’en slank, og lad fotolageret eje sit indeks og sin opbevaring.
• GPS-målinger (200.000 om dagen) bliver i FleetLink og går til Snowflake; org’en har kun brug for den seneste position til sporingssiden og dispatcherens kort.
• RouteDesks otte års historik (omkring 5 millioner leveringer) går til datavarehuset eller et arkiv, hvor den kan nås ved reklamationer. Hvad, om noget, der kommer ind i org’en, er en migreringsbeslutning til del 2.

Click to enlarge

Kontrolpunkt 1: sådan ville jeg designe det. Samme pladser som landskabet i kapitel 4 (Steve Truckings landskab), uden den dobbelte indtastning og regnearket.

Hvem ser hvad, og hvem har brug for en licens

• Detailpartnere ser kun deres egne leveringer (S2). Hver arbejdsordre bærer sin detailpartner; portalbrugere ser deres partners leveringer, og DC-ledere kun deres eget DC’s.
• Partnerbrugere har brug for en portallicens, der understøtter delingsregler og roller: Customer Community Plus eller Partner Community. Stadionpladserne fra kapitel 3: De billigste pladser får ikke den deling, dette design har brug for. Begge licenser kræver roller til de eksterne brugere, og Salesforce advarer om, at flere roller gør org’en langsommere (Experience Cloud User Licenses (opens in a new tab), på engelsk). En rolle pr. partner og pr. DC er fint; en rolle for hver butik er ikke.

Eksamensviden. Kend, hvilke eksterne licenser der har standarddeling: Customer Community Plus og Partner Community (med roller til de eksterne brugere), ikke Customer Community, som bruger sharing sets.

• Modtagere har ikke brug for en licens. Sporingssiden viser én levering via et link med et token, der udløber (S3), ikke et login.
• Hold øje med skew. Hundredtusindvis af arbejdsordrer om året, der peger på tre eller fire partnerkonti, er account data skew. En mulighed er en underordnet konto pr. DC under hver partner, som spreder børnene ni eller flere veje; arkivering af afsluttede leveringer efter reklamationsperioden holder antallet af aktive børn pr. forælder lavt. Del 2 tager fat på det.

Hvad jeg ikke ville gøre

Jeg ville ikke oprette en personkonto for hver modtager, bare fordi en modtager er en enkeltperson. Jeg ville ikke hænge en million kontakter op på tre konti. Jeg ville ikke bygge et brugerdefineret Delivery-objekt ved siden af Field Services Work Order. Jeg ville ikke samle modtagere på tværs af partnere. Jeg ville ikke lægge millioner af fotos eller GPS-målinger i core-lageret. Og jeg ville ikke kalde en samlet modtager en golden record, medmindre vi faktisk havde truffet en masterbeslutning.

Hvad der stadig er åbent

Del 1 satte skelettet; del 2 tester det. LDV-linealen i år tre (arbejdsordrer, serviceaftaler og linjer er alle i store datamængders territorium inden for to til tre år), forespørgselsdesign til listevisninger afgrænset pr. partner, de tre indgående integrationer og de tre statusfeeds, migreringen fra RouteDesk, transaktionerne på dagen og sikkerhedsdesignet bag portalen. Steve Trucking kommer også til at ændre sig. Gem dette design; du vender tilbage til det.

Hvad en arkitekt beslutter her

• Hvilke standardobjekter der bærer kernen (her Field Services), og hvilke brugerdefinerede objekter der virkelig er berettigede (her ét).
• Nøglen, der matcher hver partners ordrelinje med en levering, og hvorfor den tilhører partneren.
• Hvad modtageren er, ud fra den relation, Steve Trucking faktisk har til dem.
• Om identiteter skal samles, og hvor det er for dyrt at risikere sammenblanding.
• Hvad der bliver i org’en, hvad der bor uden for core, og hvilke licenser designet afhænger af.

Læs mere

• Steve Truckings brief og opgaver (D1, D3, DC1; på engelsk).
• 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) og Experience Cloud User Licenses (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (på engelsk), som citeret i kapitel 3.