Steve Trucking, så skulle jag designa det

🌐 Finns även 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 · العربية · עברית · Українська · हिन्दी · Русский · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Bilden är skapad med AI

Översatt med AI. Gemenskapen har inte granskat översättningen än. Läs på engelska

Modul 6 av 6 i kapitlet Masterdata och identitet, kapitel 6 i kursen Data Architect, och slutet på Del 1. Föregående: När auktoriteten delas · Nästa: Del 2 börjar med Designa för skala (coming soon)

Frågan den här kontrollpunkten besvarar: Kan du sätta ihop Del 1 i ett verkligt scenario?

Gör uppgiften först. Det här är min genomgång av uppgiften för Kontrollpunkt 1. Om du inte har ritat din egen design än, gör det innan du läser vidare. Värdet ligger i att jämföra ditt resonemang med mitt, inte i att läsa svaret.

Det här är ”Så skulle jag designa det”: en möjlig, fungerande lösning, inte det rätta svaret, med avvägningarna namngivna och mina hållningar tydliga. Vi har inte gått igenom stora datavolymer, frågedesign, integrationsmönster, migrering eller transaktioner än, och det är med flit: arkitekturen utvecklas när du lär dig mer. Men Del 1 ger oss tillräckligt för att sätta skelettet.

Börja med siffrorna

Från beskrivningen: ungefär 3 300 leveranser per arbetsdag, en miljon per år, med en tillväxt på 30 % per år. Ungefär 1,6 rader per leverans (1,6 miljoner per år); ungefär åtta statusändringar per leverans (8 miljoner per år); fyra till fem miljoner foton per år; ungefär 200 000 GPS-avläsningar per dag; ungefär 180 000 ärenden per år; tre detaljhandelspartner som skickar manifest på tre olika sätt; nio distributionscentraler; 330 lastbilar med team på två personer. Och Steve Trucking kör redan en Salesforce-org med Service Cloud, Field Service och en partnerportal. Räkna nollorna innan du ritar en enda ruta. De kommer att avgöra flera saker nedan.

Leveranskärnan: titta på moderskeppet

Leveranserna är hjärtat i det hela, och Field Service sköter redan trafikledningen. Så jag börjar med standardmodellen i Field Service, som utsnittet i kapitel 3 gjorde:

Affärsbegrepp	Objekt i Salesforce	Varför
Detaljhandelspartner (Retail Partner)	Konto (Account) (posttypen Retail Partner)	Ett företag som Steve Trucking har avtal med; bär avtal, ärenden och portalåtkomst
Partnerns personal (DC-chefer, butikspersonal)	Kontakt (Contact)	Portalanvändare måste vara kontakter
En leverans: en mottagare, en adress, en partnerorder, en dag	Arbetsorder (Work Order)	Arbetsenheten i Field Service; schemaläggning, mobilappen och servicerapporter hänger på den
Varje artikel eller tjänst: kylskåpet, installationen, bortforslingen	Arbetsorderrad (Work Order Line Item)	Delar upp arbetet, styr checklistor och fakturering
Typen av stopp: bara leverans, med installation, med bortforsling	Arbetstyp (Work Type)	Sätter tidsåtgång, kompetenser och installationschecklistan
Det schemalagda besöket och dess tidsfönster	Servicebesök (Service Appointment)	Det som Field Service schemalägger och teamets app visar
Team och lastbilar; DC:ernas trafikledningsområden	Service Resource, Service Crew, Service Territory	Field Service schemalägger ett team som en resurs
Mottagarnas frågor, partnernas reklamationer	Ärende (Case)	Servicekonsolen, tjänsteavtal (entitlements), email-to-case
Partnerns lista för tisdag vid DC:t i Phoenix	Manifest__c (anpassat)	Inget standardobjekt representerar enheten för mottagning, avstämning och omkörning

Allt annat förblir standard. Att stå emot fler anpassade objekt är medvetet: frågan i kapitel 1 var när en arkitekt ska stå emot ännu ett, och här är svaret ”nästan alltid”. Partnerns orderrad, till exempel, är inget nytt objekt. Det är arbetsordern, identifierad av partnerns referens.

Click to enlarge

Den växer fram ur finalen i kapitel 3 (Designa den fysiska modellen i Salesforce): samma objekt på samma platser, med teamet, trafikledningsområdet, ärendet och det som Kontrollpunkt 1 håller utanför core tillagt.

Nyckeln som matchar en partners order mot en leverans

Varje rad i manifestet blir en arbetsorder, länkad till sitt manifest. Nyckeln är den fråga jag helst vill ha besvarad: hur vet vi att den här raden från partnern är den där leveransen? Mitt svar: ett External ID på arbetsordern byggt av detaljhandelspartnern och partnerns egen order- och leveransreferens (ungefär KEYSTONE-PHX-8843119-1), markerat som unikt. Ett fält per källa, ett-till-ett. Det är partnerns identifierare, inte vår: ”flera identifierare för en sak” från kapitel 2, och ”partnern äger sin orderreferens” från modul 1.

Varför det spelar roll: manifesten kommer en till två dagar i förväg och revideras under dagen. Med den nyckeln gör varje omskickat eller reviderat manifest en upsert i stället för att skapa dubbletter. Revideringen uppdaterar arbetsordern, ett fält registrerar den, och en ändring av en leverans som redan har ruttplanerats larmar koordinatorn: partnerns ändring tillämpas, men flaggas tills trafikledningen bekräftar den. Det är också det som ändras jämfört med bilden i kapitel 4. I dag landar varje manifest i RouteDesk, och koordinatorerna knappar in rutterna i Salesforce och de klara stoppen tillbaka. I den här designen kommer manifesten direkt in i Salesforce, med upsert på partnerns nyckel; RouteDesk avvecklas, och inknappandet upphör. Kapitlet om integration designar de tre inkommande formaten. Databeslutet är nyckeln.

Mottagaren: personkonto, kontakt eller ingetdera?

Det här är det mest intressanta databeslutet i Del 1, så här är alternativen, och sedan mitt val.

Alternativ A: personkonton. Varje mottagare (Recipient) blir ett personkonto, länkat till varje leverans. För: standard, fungerar naturligt med Service Cloud, meddelandetjänster och konsolen, känner igen återkommande mottagare. Emot: ungefär en miljon nya mottagare per år, vart och ett ett personkonto som tar ungefär dubbelt så mycket lagring som ett företagskonto (Estimated Record Size by Object Type (opens in a new tab)), så inom två år ett av de största objekten i orgen. Och mottagarna är inte Steve Truckings kunder. De är varje detaljhandelspartners kunder, och Steve Trucking får aldrig blanda ihop en partners kund med en annans (S2).

Alternativ B: kontakter under detaljhandelspartnerns konto. Emot: en miljon kontakter under tre eller fyra konton är föräldra-barn-skew i enorm skala, långt över Salesforce vägledning om ungefär 10 000 barn per förälder (Considerations for Object Relationships (opens in a new tab); Parent-Child Data Skew (opens in a new tab)). Det här är alternativet att visa, och förkasta.

Alternativ C: mottagaren bor på leveransen. Mottagarens namn, telefon, e-post, adress och leveransanteckningar är fält på arbetsordern (adressfälten finns redan som standard där), hämtade från manifestet. För: inget nytt stort objekt; data lever exakt så länge som leveransen behöver dem; raderingen sker per leverans, enligt partnerns schema; och isoleringen mellan partner kommer gratis, eftersom varje leverans tillhör en partner. Emot: en återkommande mottagare känns inte igen som samma person.

Det är balansen som ska hittas. Kommer det någonsin att finnas ett behov av att känna igen flera leveranser som samma person, på samma plats? Att ge den personen en inloggning? Det är gränsen mellan en mottagare som behöver en egen post och mottagaruppgifter som helt enkelt är data om leveransen. Och det finns en mellanväg. Bär detaljhandelspartnerns eget kund-ID som ett fält på leveransen, ett Retail Partner Customer ID. Det skapar ingen mottagarpost, men det knyter ihop de leveranser som en partner skickar för samma kund, vilket är början på en mer enhetlig kundupplevelse, och det leder raka vägen tillbaka till detaljhandelspartnerns system, där kunden verkligen bor. Det är deras identifierare, så den betyder bara något tillsammans med partnern: en partners kund 4417 har ingenting att göra med en annans.

Enligt min professionella bedömning är alternativ C rätt val. Att mottagaren inte känns igen är acceptabelt, till och med önskvärt: Steve Trucking har ingen relation med de här personerna utöver leveransen. Det är modul 1 igen: mottagaren är partnerns kund, och partnern är auktoriteten för vem kunden är. Och det är kapitel 5: personuppgifter som hamnar på ett ställe, knutna till en leverans, är mycket lättare att skydda, bevara och radera. Och det håller mot normalformerna i kapitel 2: mottagarens uppgifter är ett-till-ett med leveransen, så de hör hemma på den. Ett separat barnobjekt för mottagaren skulle spara några upprepade värden till priset av ännu ett objekt, ännu en relation och dess overhead, och det enda sättet det skulle spara mer är genom att behandla samma person som en över detaljhandelspartnerna, vilket vi inte tänker göra. Så leveransen bär mottagaren, med Retail Partner Customer ID som vägen tillbaka till partnerns eget system.

Click to enlarge

Skulle jag förena mottagare över partnerna?

John Smith, 123 Main Street, finns i både Redrocks och Brightwaves manifest. Förmodligen samma person. Ska Steve Trucking förena dem? Nej, medvetet inte. Att förena mottagare över detaljhandelspartnerna skulle bryta mot S2: en partner får aldrig se en annan partners mottagare, och en enhetlig identitet är exakt den bro som läcker. Det är det här kapitlets hållning i praktiken: matcha för lite där sammanblandning är dyr, och här är sammanblandning väldigt dyr.

Om en detaljhandelspartner senare vill att återkommande mottagare ska kännas igen inom sina egna leveranser är det ett jobb för ett verktyg för identitetsupplösning, som det i Data 360, avgränsat till den partnern: en karta i registerstil, inte ett personkonto, och aldrig över partnerna. En karta över vem som är vem ger inget ägarskap, och den ger ingen åtkomst.

Vad som stannar i orgen, och vad som inte gör det

Kapitel 3 frågade var data ska bo. Nollorna besvarar det här:

• Aktuell status bor på servicebesöket och arbetsordern. Historiken över statusändringar, ungefär 8 miljoner per år och växande, behöver inte bo i core-orgen. Varje ändring publiceras som en händelse och sparas i datalagret, Snowflake. Orgen behåller det aktuella tillståndet; historiken finns fortfarande där för service, drift och analys, bara inte i den operativa databasen.
• Foton (fyra till fem miljoner per år, en del som visar människor eller insidan av ett hem) bor utanför core i lagring som är byggd för den volymen, uppladdade direkt från teamets app. Orgen behåller bara det den behöver: en liten indexpost per foto, eller bara ett antal och en flagga för ”obligatoriska installationsfoton klara”. Jag föredrar det lättare alternativet: håll orgen slimmad, och låt fotolagringen äga sitt index och sin lagringstid.
• GPS-avläsningar (200 000 per dag) stannar i FleetLink och går till Snowflake; orgen behöver bara den senaste positionen för spårningssidan och trafikledarens karta.
• RouteDesks åtta års historik (ungefär 5 miljoner leveranser) går till datalagret eller ett arkiv, nåbar för reklamationer. Vad som eventuellt kommer in i orgen är ett migreringsbeslut för Del 2.

Click to enlarge

Kontrollpunkt 1: så skulle jag designa det. Samma platser som landskapet i kapitel 4 (Steve Truckings landskap), utan inknappandet och kalkylarket.

Vem ser vad, och vem behöver en licens

• Detaljhandelspartnerna ser bara sina egna leveranser (S2). Varje arbetsorder bär sin detaljhandelspartner; portalanvändarna ser sin partners leveranser, och DC-cheferna bara sitt DC:s.
• Partneranvändarna behöver en portallicens som stöder delningsregler och roller: Customer Community Plus eller Partner Community. Arenans platser från kapitel 3: de billigaste platserna får inte den delning som den här designen behöver. Båda licenserna behöver roller för de externa användarna, och Salesforce varnar för att fler roller gör orgen långsammare (Experience Cloud User Licenses (opens in a new tab)). En roll per partner och per DC går bra; en roll för varje butik gör det inte.

Provkunskap. Känn till vilka externa licenser som har standarddelning: Customer Community Plus och Partner Community (med roller för de externa användarna), inte Customer Community, som använder delningsuppsättningar (sharing sets).

• Mottagarna behöver ingen licens. Spårningssidan visar en leverans genom en länk med en token som slutar gälla (S3), inte en inloggning.
• Se upp för skew. Hundratusentals arbetsorder per år som pekar på tre eller fyra partnerkonton är account data skew. Ett alternativ är ett barnkonto per DC under varje partner, vilket sprider barnen på nio eller fler; att arkivera klara leveranser efter reklamationsfönstret håller nere antalet aktiva barn per förälder. Del 2 tar sig an det.

Det här skulle jag inte göra

Jag skulle inte skapa ett personkonto för varje mottagare bara för att en mottagare är en individ. Jag skulle inte hänga en miljon kontakter på tre konton. Jag skulle inte bygga ett anpassat leveransobjekt bredvid arbetsordern i Field Service. Jag skulle inte förena mottagare över partnerna. Jag skulle inte lägga miljontals foton eller GPS-avläsningar i core-lagringen. Och jag skulle inte kalla en förenad mottagare för en golden record om vi inte faktiskt hade fattat ett beslut om masterdata.

Det som fortfarande är öppet

Del 1 satte skelettet; Del 2 prövar det. LDV-linjalen vid år tre (arbetsorder, servicebesök och rader hamnar alla i området för stora volymer inom två till tre år), frågedesign för listvyer avgränsade per partner, de tre inkommande integrationerna och de tre statusflödena, migreringen från RouteDesk, transaktionerna under dagen och säkerhetsdesignen bakom portalen. Steve Trucking kommer också att förändras. Behåll den här designen; du kommer att återvända till den.

Vad en arkitekt bestämmer här

• Vilka standardobjekt som bär kärnan (här de i Field Service), och vilka anpassade objekt som verkligen är motiverade (här ett).
• Nyckeln som matchar varje partners orderrad mot en leverans, och varför den tillhör partnern.
• Vad mottagaren är, utifrån den relation som Steve Trucking faktiskt har med mottagarna.
• Om identiteter ska förenas, och var sammanblandning är för dyr att riskera.
• Vad som stannar i orgen, vad som bor utanför core, och vilka licenser designen är beroende av.

Utforska vidare

• Steve Truckings beskrivning och uppgifter (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) och Experience Cloud User Licenses (opens in a new tab) (på engelska, kontrollerad 2026-10-14).
• Salesforce Developers, Parent-Child Data Skew (opens in a new tab) (på engelska), som citeras i kapitel 3.