Designa den fysiska modellen i Salesforce

🌐 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 10 av 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kursen Data Architect. Varje modul står på egna ben. Föregående: Håll data konsistenta · Nästa: kapitlets studieguide, sedan nästa kapitel, Förstå företagets data

Frågan den här modulen besvarar: Hur gör vi vår logiska modell till en arkitektur i Salesforce?

Hela det här kapitlet har varit ett enda långt argument för att plattformen har en form: standardobjekt och anpassade objekt, platser där data kan bo, fälttyper, relationer, ägarskap, licenser, konsistensregler, lagring och skala. Var och en kan ändra hur den logiska modellen från kapitel 2 byggs. Nu sätter vi ihop det på en del av Steve Trucking.

En del, inte hela företaget. Ett misstag jag ser arkitekter göra är att försöka lösa hela företaget i ett enda diagram. Jag vill ha något vi kan resonera om: en detaljhandelspartner (Retail Partner) skickar ett manifest, Steve Trucking levererar det som står på det, och vi sparar det vi behöver om varje leverans. Sedan fattar vi de fysiska besluten ett i taget. Den fullständiga designen är kontrollpunkten för del 1.

Börja med det vi redan vet

Kapitel 2 gjorde det konceptuella arbetet: detaljhandelspartner, mottagare (Recipient), manifest (Manifest), leverans (Delivery), leveransrad (Delivery Item), typen av stopp, team (Crew), lastbil (Truck), distributionscentral (Distribution Center), foton. Vi namngav relationerna och frågade vad de betyder. Det tänker jag inte upprepa. Frågan nu är hur de begreppen lever i Salesforce. Ett faktum från uppdragsbeskrivningen spelar roll direkt: Steve Trucking kör redan Field Service för bokningar, team och mobilappen.

Detaljhandelspartner: hitta inte på ett konto

En detaljhandelspartner är ett företag som Steve Trucking arbetar åt. Salesforce har redan ett objekt designat för företag: konto (Account). Ren passform. Så inget Retail_Partner__c bara för att verksamheten säger ”partner”. Det är ett konto, med en posttyp för detaljhandelspartner som skiljer det från andra organisationer, och med det följer avtal, ärenden, kontakter för DC-cheferna och portalåtkomst för de kontakterna. Lätt beslut. Alla är inte det.

Partnerns ordernummer är inte vårt ID

Varje detaljhandelspartner skickar sina egna referenser. En partners order ser ut som 8843119, en annans som A-984732. De numren spelar roll, men vems är de? Partnerns. Salesforce har sitt eget post-ID, och partnern har den referens den använder när den pratar med oss. Båda kan finnas; det är kapitel 2:s ”en sak, flera identifierare”.

Så partnerns referens blir ett External ID som integrationen använder för att matcha uppdateringar. Och eftersom två partner kan använda samma nummer är det unika ID:t partnern plus referensen, inte referensen ensam. Gör inte en partners nummer till leveransens universella ID bara för att det kom först, och låt inte en integration söka i ett textfält varje gång den behöver hitta en post.

Leverans: titta på moderskeppet

Här är det frestande att skapa Delivery__c. Verksamheten sa ”leverans”, så vi behöver ett leveransobjekt. Det är precis vad jag inte vill att du gör först. Titta på moderskeppet, som vi gjorde i modul 2. Vad har Salesforce redan för arbete som utförs på en plats, med en livscykel, rader, schemaläggning och ett team ute på fältet? Field Service arbetsorder (Work Order): Salesforce beskriver den som fältservicearbete som ska utföras åt en kund (WorkOrder (opens in a new tab)). Det schemalagda besöket och dess tidsfönster är servicebesöket (Service Appointment), och det är det som trafikledningen schemalägger och teamets app visar.

Så leverans → arbetsorder. Inte för att orden stämmer; det gör de inte. Utan för att beteendet stämmer med den plattformsförmåga vi redan betalar för och tänker använda. Ett standardobjekt behöver inte dela verksamhetens ordförråd. Det måste representera begreppet korrekt.

Click to enlarge

Steg 1 av 4: moderskeppet. Varje kort är affärsbegreppet, med sitt Salesforce-objekt under.

Men standardobjekt kommer med bagage

Den andra halvan: arbetsordern är inte gratis. Den tar med sig licenser för Field Service, sina egna relationer, säkerhetsbeteende, obligatoriska fält, automatisering och livscykel, och andra delar av plattformen förväntar sig att den beter sig på ett visst sätt. Vi väljer den för att passformen är ren och för att vi använder det som är byggt runt den. Om Steve Trucking inte ville ha något av Field Service och modellen kämpade emot processen i varje steg skulle jag tänka om. Arkitekturen är passformen, inte etiketten.

Leveransrader: följ modellen

När leveransen väl är en arbetsorder, titta på resten av den modellen innan du hittar på något. En arbetsorderrad (Work Order Line Item) är en deluppgift på en arbetsorder (WorkOrderLineItem (opens in a new tab)): kylskåpet, installationen, bortforslingen. Så leveransrad → arbetsorderrad. Lägg märke till att det första beslutet formade det andra. Vi väljer inte ett objekt för varje entitet för sig. Ta till dig en modell, och förstå resten av den innan du bygger egna strukturer runt den.

Vilken typ av stopp är det här?

Hos Steve Trucking är ett stopp antingen bara leverans, leverans med installation eller leverans med bortforsling, och varje typ har sin egen tidsåtgång, sina egna teamfärdigheter och sin egen checklista för installation. I kapitel 2 bestämde vi att det är en entitet, inte en etikett. Field Service har redan en: arbetstyp (Work Type), en mall för en typ av arbete som kan tillämpas på arbetsordrar och rader (WorkType (opens in a new tab)). Så typ av stopp → arbetstyp. Återigen, inte för att något som heter Work Type finns, utan för att begreppet och beteendet stämmer överens.

Click to enlarge

Steg 2 av 4: följ modellen. Rader och arbetstyp följer med arbetsordern.

Manifest: nu vill jag ha ett anpassat objekt

Finns det ett standardobjekt för ”partnerns lista för tisdag på DC:n i Phoenix”? Inte riktigt, och jag tänker inte tvinga in det i ett orelaterat objekt bara för att kunna säga att vi höll oss till standard. Manifest → Manifest__c. Det är enheten för mottagning: var det kom ifrån (en fil, en API-batch), när, dess status och summor, och, när en partner skickar om det samma dag, vad som jämförs. Varje rad i manifestet blir en arbetsorder som länkar tillbaka till det.

Anpassat är inget misslyckande. Det är vad plattformen ger oss när ett begrepp saknar ett rent hem bland standardobjekten. Misstaget är inte att skapa ett anpassat objekt; det är att skapa ett utan att kolla om plattformen redan har begreppet.

Click to enlarge

Steg 3 av 4: det enda anpassade objektet, där inget standardobjekt passar.

Foton: bara för att Salesforce kan lagra det betyder det inte att det ska

”Vi behöver leveransfotona i Salesforce.” Vad betyder ”i Salesforce”? Användarna behöver se dem från Salesforce, ja. Betyder det att bildfilerna måste bo i lagringen på core? Inte nödvändigtvis. Räkna nollorna: ungefär fyra foton per leverans, fler med installationer, vid en miljon leveranser om året blir fyra till fem miljoner foton om året, och leveranserna växer med 30 % om året.

Så min utgångspunkt: gör inte core-orgen till ett gigantiskt fotoarkiv för att användarna behöver komma åt foton. Filerna hör hemma i lagring byggd för den volymen, utanför core, och Salesforce sparar det som behövs för att hitta och visa dem: en referens, ett antal eller en liten indexpost per foto, och en flagga för att de obligatoriska installationsfotona är kompletta. Åtkomst till data och var data fysiskt bor är två olika frågor. Där kommer modul 4 tillbaka.

Fält: gör betydelsen synlig

Arbetsordern behöver fält: partnerns referens, leveransfönstret, den faktiska leveranstiden, status, anteckningar som ”portkod” eller ”hund på gården”. Jag tänker inte göra det här till en fältkatalog; det gjorde modul 6. Ställ frågorna för vart och ett: vad det betyder, vem som äger det, om det ändras, om det är en identifierare, ett kontrollerat ordförråd, lagrat eller härlett, känsligt. Partnerns referens är External ID, så dess unikhet är en del av integrationskontraktet, inte bara en kryssruta. Den faktiska leveranstiden är ett ögonblick, alltså Date/Time. Status styr beteende, alltså en kontrollerad lista, aldrig fritext. Och leveransanteckningar om någons hem är personuppgifter, så de klassificeras. Varje fält går att spåra tillbaka till en betydelse.

Relationer: koppla inte bara ihop lådorna

Konto till arbetsorder, arbetsorder till dess rader, manifest till arbetsorder, arbetstyp som beskriver stoppet. Ställ sedan frågorna från modul 7 för varje linje: kan barnet finnas på egen hand, vem äger det, ärvs åtkomsten, kan det flyttas, vad händer vid radering, hur många barn kan hopa sig? Varenda arbetsorder under en handfull konton för detaljhandelspartner betyder hundratusentals barn per förälder: en skew-fråga som vi besvarar i del 2. Och för standardrelationerna i Field Service, kolla hur Salesforce redan har byggt dem i stället för att anta att de stämmer med det vi själva hade designat. När du tar till dig en standardmodell tar du till dig besluten som Salesforce fattade i den. Förstå dem innan du bygger ovanpå.

Ägarskap och mottagaren: låt inte standardvärdet bestämma

Två beslut som ett standardvärde gärna skulle fatta åt oss.

Vem äger en leverans? Det besvarade vi i modul 8, och svaret gäller direkt för arbetsordern: ägarskapet styr ingens åtkomst här, så integrationsanvändaren äger de arbetsordrar den skapar. Trafikledarna ser sin distributionscentrals, teamen ser sina rutters, och varje detaljhandelspartner ser sina egna via portalen, allt genom delning, inte ägarskap. Integrationsanvändaren har ingen roll och hålls utanför de publika grupper som våra delningsregler använder, eftersom den med 3 300 om dagen passerar 10 000 poster på tre dagar. Och vi skriver ned vad som händer om den användaren någon gång byts ut.

Vad är mottagaren? En kontakt? Ett personkonto? Något som bara sparas på leveransen? Det beror på om Steve Trucking alls har en relation med de här människorna (de är detaljhandelspartnernas kunder), om en partner någonsin får se en annans, hur länge deras personuppgifter får sparas, och skalan: ungefär en miljon nya mottagare om året. Allt det har vi inte än, och det är okej. Ibland är det rätta svaret vi vet inte tillräckligt än. Skriv ned frågan och skaffa informationen; begrav inte osäkerheten i ett anpassat objekt. Vi besvarar den vid kontrollpunkten för del 1, när kapitel 4 till 6 har gett oss bilden av företaget och dess masterdata.

Konsistens: skydda modellen i rätt lager

Stegen från modul 9 gäller: partnerns referens är ett unikt External ID, så ett omskickat manifest gör upsert i stället för att skapa dubbletter; status är en begränsad lista; den faktiska leveranstiden är obligatorisk först när status säger Delivered; ett installationsstopp kan inte stängas utan sin checklista och sina foton. Inte ett enda gigantiskt flöde. Varje regel på sitt eget steg.

Var varje del bor

En sväng till över vår del, med frågan från modul 4: var bor varje bit data? I min kursdeck är det en enda bild, logiskt mot fysiskt: de logiska entiteterna från kapitel 2, och var var och en fysiskt hamnar: på core, som ett sObject (__c om det är anpassat) eller ett big object (__b), eller utanför core, som ett externt objekt (__x) eller data som aldrig kommer in i Salesforce alls.

• På core, i dagligt arbete: kontot, arbetsordrarna och deras rader, servicebesöken, arbetstyperna, Manifest__c.
• På core, arkiverat: leveranser äldre än tre år flyttas till Delivery History, ett big object, fortfarande kvar för reklamationer, ute i förrådet.
• Refererat: detaljhandelspartnerns egna orderuppgifter stannar i partnerns system; vi sparar partnerns referens som ett External ID och når resten via ett externt objekt eller integrationen när någon behöver det.
• Utanför core: fotona, i lagring byggd för miljontals bilder, med en länk från arbetsordern.

Det är den fysiska modellen: inte bara vilket objekt, utan vilket hem.

Titta nu på hela utsnittet

• Detaljhandelspartner → konto, med en posttyp för detaljhandelspartner; DC-chefer som kontakter.
• Leverans → arbetsorder i Field Service, schemalagd via ett servicebesök.
• Leveransrad → arbetsorderrad.
• Typ av stopp → arbetstyp.
• Manifest → det anpassade Manifest__c.
• Partnerreferens → External ID på arbetsordern, unikt per partner.
• Foton → lagrade utanför core; Salesforce sparar referensen och flaggan för fullständighet.
• Leveranshistorik → arkiveras till ett big object efter tre år.
• Ägarskap → integrationsanvändaren, med åtkomst via delning (modul 8).
• Mottagare → öppen, till kontrollpunkten för del 1.

Click to enlarge

Steg 4 av 4: hela delen, på core, arkiverat och utanför core. Varje linje är en lookup: Salesforce byggde Field Service på lookup-relationer, och vi tar till oss besluten tillsammans med det.

Diagrammet är inte arkitekturen

Jag kan ge dig det där diagrammet, och det räcker inte. Arkitekturen är resonemanget bakom det. Varför konto? Ett företag med ren passform. Varför arbetsorder och inte Delivery__c? Leveransen beter sig som fältarbete, och Field Service finns redan på plats. Varför ett anpassat manifest? Inget rent hem bland standardobjekten. Varför är fotona inte bara Files? Volym och lagringsekonomi. Varför ett External ID? Ett annat system behöver ett stabilt ID över gränsen. Varför äger integrationsanvändaren arbetsordrarna? Ägarskapet styr inte åtkomsten här, och det håller granskningsspåret ärligt. Varför är mottagaren fortfarande öppen? Vi har inte besvarat tillräckligt många frågor än. Linjerna är resultatet; besluten skapade dem.

Så här är vanan jag vill att du tar med dig från kapitel 3. Peka på vad som helst i en fysisk modell och fråga varför? Varför det här objektet, den här typen, den här relationen, den här ägaren, den här platsen, den här regeln? Du ska kunna spåra svaret bakåt: från konfigurationen, till den fysiska modellen, till den logiska modellen, till affärskravet. Kan du inte det har någon designat från Setup.

Och du har säkert märkt siffrorna vi inte har räknat igenom helt: leveranser per partner, rader, foton, lagringstid, arkivering. Bra. Fråga efter antalet nollor innan du låser en design: en modell som fungerar fint vid femtiotusen poster kan bete sig helt annorlunda vid femhundra miljoner. Det är del 2.

Bortom provet: vad AI ändrar. Ge en AI uppdragsbeskrivningen för Steve Trucking så tar den fram ett schema på några sekunder: konto, arbetsorder, anpassade objekt, fält, till och med metadata för deploy. Det är en fantastisk accelerator, och det är inte granskningen. Arkitektens jobb flyttas till att kontrollera mappningarna och deras konsekvenser: passform, licenser, ägarskap, livscykel, skala, unika ID:n, säkerhet och vad som stannar utanför plattformen. AI är raketboostern; den talar inte om för dig om du pekar åt rätt håll.

Vad en arkitekt bestämmer här

• Hur varje affärsbegrepp mappas till Salesforce: ett standardobjekt, ett anpassat objekt eller något utanför core.
• Vilka identifierare, fält och relationer som implementerar affärsbetydelsen utan att i tysthet ändra den.
• Vilket plattformsbeteende och vilka licenser som följer med en standardmodell du tar till dig.
• Vilka beslut om ägarskap, livscykel, konsistens, lagring och skala som måste fattas innan designen är klar.
• Vilka frågor som uttryckligen lämnas öppna, i stället för att döljas bakom ett godtyckligt implementeringsval.

I början av det här kapitlet frågade vi hur modellen ska leva i Salesforce. Det är dataarkitektur i Salesforce: inte att skapa objekt, inte att plugga in Setup, inte att rita snyggare lådor, utan att medvetet anpassa affärsmodellen till plattformens form. Varje struktur är ett åtagande. Gör de åtaganden du kan förklara.

Utforska vidare

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) och WorkType (opens in a new tab) (på engelska, kontrollerad 2026-10-02).
• Uppdragsbeskrivningen för Steve Trucking.