Steve Trucking, slik ville jeg designet det
Finnes også på 28 språk
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 · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 6 av 6 i kapitlet Masterdata og identitet, kapittel 6 i kurset Data Architect, og slutten på del 1. Forrige: Når autoriteten er delt · Neste: Del 2 begynner med Design for skala (coming soon)
Spørsmålet dette kontrollpunktet besvarer: Kan du sette sammen del 1 på et virkelig scenario?
Prøv oppgaven først. Dette er min gjennomgang av oppgaven til kontrollpunkt 1. Hvis du ikke har tegnet ditt eget design ennå, gjør det før du leser videre. Verdien ligger i å sammenligne resonnementet ditt med mitt, ikke i å lese svaret.
Dette er «slik ville jeg designet det»: en mulig, gjennomførbar løsning, ikke svaret, med avveiningene navngitt og standpunktene mine tatt. Vi har ikke dekket store datavolumer, spørringsdesign, integrasjonsmønstre, migrering eller transaksjoner ennå, og det er med vilje: arkitekturen utvikler seg etter hvert som du lærer mer. Men del 1 gir oss nok til å sette skjelettet.
Start med tallene
Section titled “Start med tallene ”Fra beskrivelsen: rundt 3 300 leveringer per arbeidsdag, én million i året, med 30 % vekst per år. Rundt 1,6 linjer per levering (1,6 millioner i året); rundt åtte statusendringer per levering (8 millioner i året); fire til fem millioner bilder i året; rundt 200 000 GPS-avlesninger om dagen; rundt 180 000 saker i året; tre detaljhandelspartnere (Retail Partners) som sender manifester på tre forskjellige måter; ni distribusjonssentre; 330 lastebiler med team på to personer. Og Steve Trucking kjører allerede én Salesforce-org med Service Cloud, Field Service og en partnerportal. Tell nullene før du tegner en eneste boks. De kommer til å avgjøre flere ting nedenfor.
Leveringskjernen: se til moderskipet
Section titled “Leveringskjernen: se til moderskipet ”Leveringene er hjertet i det hele, og Field Service håndterer allerede utsendingen. Så jeg starter med standardmodellen i Field Service, slik utsnittet i kapittel 3 gjorde:
| Forretningsbegrep | Salesforce-objekt | Hvorfor |
|---|---|---|
| Detaljhandelspartner (Retail Partner) | Konto (Account) (posttypen Retail Partner) | En virksomhet Steve Trucking har kontrakt med; bærer kontrakter, saker og portaltilgang |
| Partnerens ansatte (DC-ledere, butikkansatte) | Kontakt (Contact) | Portalbrukere må være kontakter |
| Én levering: én mottaker, én adresse, én partnerordre, én dag | Arbeidsordre (Work Order) | Arbeidsenheten i Field Service; planlegging, mobilappen og servicerapporter henger på den |
| Hver vare eller tjeneste: kjøleskapet, monteringen, bortkjøringen | Arbeidsordrelinje (Work Order Line Item) | Deler opp arbeidet, styrer sjekklister og fakturering |
| Typen stopp: bare levering, med montering, med bortkjøring | Arbeidstype (Work Type) | Bestemmer varighet, ferdigheter og monteringssjekklisten |
| Det planlagte besøket og tidsvinduet | Serviceavtale (Service Appointment) | Det Field Service planlegger og teamets app viser |
| Team og lastebiler; DC-enes utkjøringsområder | Service Resource, Service Crew, Service Territory (serviceressurs, serviceteam, serviceområde) | Field Service planlegger et team som én ressurs |
| Henvendelser fra mottakere, reklamasjoner fra partnere | Sak (Case) | Servicekonsollen, rettigheter (entitlements), email-to-case |
| Partnerens liste for tirsdag ved DC-et i Phoenix | Manifest__c (egendefinert) | Ingenting standard representerer enheten for mottak, avstemming og ny avspilling |
Alt annet forblir standard. Å stå imot flere egendefinerte objekter er bevisst: spørsmålet i kapittel 1 var når en arkitekt bør stå imot enda ett, og her er svaret «nesten alltid». Partnerens ordrelinje, for eksempel, er ikke et nytt objekt. Det er arbeidsordren, identifisert med partnerens referanse.
Den vokser ut av finalen i kapittel 3 (Design den fysiske modellen i Salesforce): de samme objektene på de samme stedene, med teamet, utkjøringsområdet, saken og det kontrollpunkt 1 holder utenfor core lagt til.
Nøkkelen som matcher en partners ordre med en levering
Section titled “Nøkkelen som matcher en partners ordre med en levering ”Hver manifestlinje blir én arbeidsordre, koblet til manifestet sitt. Nøkkelen er spørsmålet jeg aller helst vil ha svar på: hvordan vet vi at denne linjen fra partneren er den leveringen? Mitt svar: en External ID på arbeidsordren bygd av detaljhandelspartneren og partnerens egen ordre- og leveringsreferanse (noe sånt som KEYSTONE-PHX-8843119-1), merket unique (unik). Ett felt per kilde, én-til-én. Det er partnerens identifikator, ikke vår: «flere identifikatorer for én ting» fra kapittel 2, og «partneren eier ordrereferansen sin» fra modul 1.
Hvorfor det betyr noe: manifestene kommer én til to dager i forveien og blir revidert samme dag. Med den nøkkelen blir hvert manifest som sendes på nytt eller revideres, upsertet i stedet for å lage duplikater. Revisjonen oppdaterer arbeidsordren, et felt registrerer den, og en endring i en levering som allerede er ruteplanlagt, varsler koordinatoren: partnerens endring blir gjennomført, men flagget til utsendingen bekrefter den. Det er også dette som endrer seg fra bildet i kapittel 4. I dag havner hvert manifest i RouteDesk, og koordinatorene taster rutene inn i Salesforce og fullførte stopp tilbake. I dette designet kommer manifestene rett inn i Salesforce, upsertet med partnerens nøkkel; RouteDesk pensjoneres, og den doble inntastingen tar slutt. Integrasjonskapitlet designer de tre innkommende formatene. Databeslutningen er nøkkelen.
Mottakeren: personkonto, kontakt eller ingen av delene?
Section titled “Mottakeren: personkonto, kontakt eller ingen av delene? ”Dette er den mest interessante databeslutningen i del 1, så her er alternativene, og deretter mitt valg.
Alternativ A: personkontoer. Hver mottaker (Recipient) blir en personkonto, koblet til hver levering. For: standard, fungerer naturlig med Service Cloud, meldinger og konsollen, kjenner igjen mottakere som kommer tilbake. Mot: rundt én million nye mottakere i året, hver en personkonto med omtrent dobbelt så stor lagring som en bedriftskonto (Estimated Record Size by Object Type (opens in a new tab)), så innen to år et av de største objektene i orgen. Og mottakerne er ikke Steve Truckings kunder. De er kundene til hver enkelt detaljhandelspartner, og Steve Trucking må aldri blande én partners kunde med en annens (S2).
Alternativ B: kontakter under detaljhandelspartnerens konto. Mot: én million kontakter under tre eller fire kontoer er parent-child skew i enorm skala, langt forbi Salesforces veiledning om rundt 10 000 barn per forelder (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Dette er alternativet du viser, og forkaster.
Alternativ C: mottakeren bor på leveringen. Mottakerens navn, telefon, e-post, adresse og leveringsnotater er felt på arbeidsordren (adressefeltene er allerede standard der), hentet fra manifestet. For: ikke noe nytt stort objekt; dataene lever akkurat så lenge leveringen trenger dem; sletting skjer per levering, etter partnerens tidsplan; og isolasjonen mellom partnerne følger med gratis, fordi hver levering tilhører én partner. Mot: en mottaker som kommer tilbake, blir ikke kjent igjen som samme person.
Det er den balansen du må finne. Kommer det noen gang til å bli behov for å kjenne igjen flere leveringer som samme person, på samme sted? Gi den personen en innlogging? Det er grensen mellom en mottaker som trenger en egen post, og mottakeropplysninger som rett og slett er data om leveringen. Og det finnes en mellomvei. Ta med detaljhandelspartnerens egen kunde-ID som et felt på leveringen, en Retail Partner Customer ID (partnerens kunde-ID). Den oppretter ingen mottakerpost, men den binder sammen leveringene en partner sender for samme kunde, som er starten på en mer samlet kundeopplevelse, og den leder rett tilbake til detaljhandelspartnerens system, der den kunden egentlig bor. Det er partnerens identifikator, så den betyr bare noe sammen med partneren: én partners kunde 4417 har ingenting med en annens å gjøre.
Etter min faglige vurdering er alternativ C det riktige valget. At mottakeren ikke blir kjent igjen, er akseptabelt, til og med ønskelig: Steve Trucking har ingen relasjon til disse menneskene utover leveringen. Det er modul 1 igjen: mottakeren er partnerens kunde, og partneren er autoriteten for hvem de er. Og det er kapittel 5: personopplysninger som havner på ett sted, knyttet til én levering, er langt enklere å beskytte, oppbevare og slette. Og det holder mot normalformene i kapittel 2: mottakerens opplysninger er én-til-én med leveringen, så de hører hjemme på den. Et eget mottakerbarn ville spart noen gjentatte verdier, på bekostning av enda et objekt, enda en relasjon og kostnadene med dem, og den eneste måten det kunne spart mer på, er ved å behandle samme person som én på tvers av detaljhandelspartnere, og det gjør vi ikke. Så leveringen bærer mottakeren, med partnerens kunde-ID som veien tilbake til partnerens eget system.
Ville jeg samlet mottakere på tvers av partnere?
Section titled “Ville jeg samlet mottakere på tvers av partnere? ”John Smith, 123 Main Street, dukker opp i manifestet til Redrock og til Brightwave. Sannsynligvis samme person. Bør Steve Trucking samle dem? Nei, bevisst ikke. Å samle mottakere på tvers av detaljhandelspartnere ville bryte S2: en partner må aldri se en annen partners mottakere, og en samlet identitet er akkurat den broen som lekker. Det er kapitlets standpunkt i praksis: match for lite der sammenblanding er kostbart, og her er sammenblanding svært kostbart.
Hvis en detaljhandelspartner senere vil kjenne igjen mottakere som kommer tilbake innenfor sine egne leveringer, er det en jobb for et verktøy for identitetsoppløsning, som identitetsoppløsningen i Data 360, avgrenset til den partneren: et kart i registerstil, ikke en personkonto, og aldri på tvers av partnere. Et kart over hvem som er hvem, gir ikke eierskap, og det gir ikke tilgang.
Hva som blir i orgen, og hva som ikke gjør det
Section titled “Hva som blir i orgen, og hva som ikke gjør det ”Kapittel 3 spurte hvor data bør bo. Nullene svarer på det her:
- Gjeldende status bor på serviceavtalen og arbeidsordren. Historikken over statusendringer, rundt 8 millioner i året og voksende, trenger ikke å bo i core-orgen. Hver endring publiseres som en hendelse og lagres i datavarehuset, Snowflake. Orgen beholder gjeldende tilstand; historikken er der fortsatt for service, drift og analyse, bare ikke i den operative databasen.
- Bilder (fire til fem millioner i året, noen av dem viser mennesker eller innsiden av et hjem) bor utenfor core i lagring bygd for det volumet, lastet opp rett fra teamets app. Orgen beholder bare det den trenger: en liten indekspost per bilde, eller bare et antall og et flagg for «påkrevde monteringsbilder fullført». Jeg foretrekker det lettere alternativet: hold orgen slank, og la bildelageret eie sin egen indeks og oppbevaring.
- GPS-avlesninger (200 000 om dagen) blir i FleetLink og går til Snowflake; orgen trenger bare den siste posisjonen for sporingssiden og utkjøringskoordinatorens kart.
- RouteDesks åtte år med historikk (rundt 5 millioner leveringer) går til datavarehuset eller et arkiv, tilgjengelig for reklamasjoner. Hva som eventuelt kommer inn i orgen, er en migreringsbeslutning for del 2.
Kontrollpunkt 1: slik ville jeg designet det. Samme plasser som landskapet i kapittel 4 (Steve Truckings landskap), med den doble inntastingen og regnearket borte.
Hvem ser hva, og hvem trenger en lisens
Section titled “Hvem ser hva, og hvem trenger en lisens ”- Detaljhandelspartnerne ser bare sine egne leveringer (S2). Hver arbeidsordre bærer detaljhandelspartneren sin; portalbrukerne ser partnerens leveringer, og DC-lederne bare leveringene til sitt eget DC.
- Partnerbrukerne trenger en portallisens som støtter delingsregler og roller: Customer Community Plus eller Partner Community. Stadionsetene fra kapittel 3: de billigste setene får ikke den delingen dette designet trenger. Begge lisensene trenger roller for de eksterne brukerne, og Salesforce advarer om at flere roller gjør orgen tregere (Experience Cloud User Licenses (opens in a new tab)). En rolle per partner og per DC er greit; en rolle for hver butikk er det ikke.
Eksamenskunnskap. Vit hvilke eksterne lisenser som har standard deling: Customer Community Plus og Partner Community (med roller for de eksterne brukerne), ikke Customer Community, som bruker sharing sets.
- Mottakerne trenger ingen lisens. Sporingssiden viser én levering gjennom en lenke med et token som utløper (S3), ikke en innlogging.
- Pass på skew. Hundretusener av arbeidsordrer i året som peker på tre eller fire partnerkontoer, er account data skew. Ett alternativ er en barnekonto per DC under hver partner, som sprer barna på ni eller flere foreldre; å arkivere fullførte leveringer etter reklamasjonsfristen holder antallet aktive barn per forelder lavt. Del 2 tar fatt i det.
Det jeg ikke ville gjort
Section titled “Det jeg ikke ville gjort ”Jeg ville ikke opprettet en personkonto for hver mottaker fordi en mottaker er et individ. Jeg ville ikke hengt én million kontakter på tre kontoer. Jeg ville ikke bygd et egendefinert leveringsobjekt ved siden av arbeidsordren i Field Service. Jeg ville ikke samlet mottakere på tvers av partnere. Jeg ville ikke lagt millioner av bilder eller GPS-avlesninger i core-lagringen. Og jeg ville ikke kalt en samlet mottaker en golden record med mindre vi faktisk hadde tatt en mastringsbeslutning.
Det som fortsatt er åpent
Section titled “Det som fortsatt er åpent ”Del 1 satte skjelettet; del 2 tester det. LDV-linjalen i år tre (arbeidsordrer, serviceavtaler og linjer er alle i stort-volum-territorium innen to til tre år), spørringsdesign for listevisninger avgrenset per partner, de tre innkommende integrasjonene og de tre statusstrømmene, migreringen fra RouteDesk, transaksjonene på leveringsdagen, og sikkerhetsdesignet bak portalen. Steve Trucking kommer også til å endre seg. Ta vare på dette designet; du kommer tilbake til det.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvilke standardobjekter som bærer kjernen (her de fra Field Service), og hvilke egendefinerte objekter som virkelig er berettiget (her ett).
- Nøkkelen som matcher hver partners ordrelinje med en levering, og hvorfor den tilhører partneren.
- Hva mottakeren er, basert på relasjonen Steve Trucking faktisk har til dem.
- Om identiteter skal samles, og hvor sammenblanding er for kostbart å risikere.
- Hva som blir i orgen, hva som bor utenfor core, og hvilke lisenser designet er avhengig av.
Les mer
Section titled “Les mer ”- Beskrivelsen av Steve Trucking og oppgavene (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) og Experience Cloud User Licenses (opens in a new tab), på engelsk, kontrollert 2026-10-14.
- Salesforce Developers, Parent-Child Data Skew (opens in a new tab), på engelsk, som sitert i kapittel 3.