Gör modellen till 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)
Modul 6 av 6 i kapitlet Modellera data för mening, kapitel 2 i kursen Data Architect. Varje modul står på egna ben. Föregående: Designa till tredje normalformen, backa sedan · Nästa: kapitlets studieguide, sedan nästa kapitel: Dataarkitektur i Salesforce
Frågan den här modulen besvarar: Hur blir en logisk datamodell en fysisk datamodell i Salesforce?
Äntligen ska vi prata om Salesforce. Om du har stått emot frestelsen att göra varje ruta till ett objekt får du göra det nu. Men lägg märke till ordningen vi kom i: vi förstod verksamheten, beskrev data, lade varje faktum där det hör hemma och bestämde var vi medvetet skulle böja på det. Först nu frågar jag hur Salesforce ska implementera det. Det är förloppet jag vill att du kommer ihåg: konceptuell → logisk → fysisk. Den konceptuella modellen beskriver verksamheten. Den logiska modellen beskriver data. Den fysiska modellen beskriver hur vi faktiskt ska bygga det.
Sitt, stanna, modellera
Section titled “Sitt, stanna, modellera ”Det fysiska steget är lättast att se på något litet, så husdjuren får gå först.
Vilka är företagen och människorna? Uppfödaren är ett företag, så den blir ett konto (Account) med posttypen Uppfödare. Ägaren är också ett konto, eller ett personkonto, med posttypen Ägare. Två sorter av samma standardobjekt, sida vid sida högst upp i diagrammet, precis där de har funnits sedan modul 1.
Vad har inget standardhem? Husdjur, Ras, Trick, Husdjurstrick och Trickbedömning blir anpassade objekt. Och minns du arten vi kopierade till husdjuret i modul 5? Här får den sitt jobb: den blir husdjurets posttyp, Hund eller Katt. Ett objekt med två posttyper, var och en med egen sidlayout och egna plocklistvärden, i stället för ett Hund-objekt och ett Katt-objekt.
Vilka relationer är master-detail? Jag använder master-detail bara där barnet aldrig kommer att byta förälder. Ett husdjurstrick hör till sitt husdjur hela livet, och varje trickbedömning hör till sitt husdjurstrick, så båda är master-detail. Det lönar sig direkt: master-detail är det som låter husdjuret ha ett sammanställningsfält (roll-up summary) över sina husdjurstrick, så att räknaren Kända trick från modul 5 håller jämna steg av sig själv. Husdjur byter däremot hem ibland, så ägaren är en lookup-relation.
Vilka är lookup-relationer? Salesforce rekommenderar inte fler än 10 000 barn på en enda förälder. Ett populärt trick som Sitt, en vanlig ras eller en stor uppfödare kan lätt gå över det, så husdjurstricket pekar på sitt trick med en lookup, och husdjuret pekar på sin ras och sin uppfödare på samma sätt. Och undvik polymorfa relationer där du kan, den sort där ett fält kan peka på flera objekttyper. De är bekväma första dagen och svårare för allt som måste läsa dem senare: rapporter, integrationer och nu agenter.
Vad stannar utanför plattformen? Om husdjuret bär ett GPS-halsband som rapporterar var det är behöver den positionen inte kopieras in alls. Den kan vara ett externt objekt, som läses live från halsbandets spårningssystem.
Varje beslut i det diagrammet går att spåra tillbaka till något vi bestämde tidigare, och det är poängen. Nu samma steg för Steve Trucking.
Börja med den logiska modellen
Section titled “Börja med den logiska modellen ”Vår logiska modell för Steve Trucking innehåller nu detaljhandelspartner, distributionscentral, manifest, leverans, leveransrad, mottagare, rutt, stopp, team, lastbil och teamtilldelning. Det är affärsbegrepp, och nu kan jag börja mappa dem till Salesforce.
En detaljhandelspartner kanske är ett konto (Account). En leverans kanske motsvarar något som Salesforce redan har för schemalagt arbete ute på fältet, eller så blir den ett anpassat objekt. Ett manifest har inget standardobjekt som passar, så det blir troligen anpassat. Och mottagaren är en genuint svår fråga: ett personkonto (Person Account), en kontakt (Contact) eller helt enkelt information på leveransen? Den besvarar vi ordentligt i nästa kapitel.
Det viktiga ordet är fortfarande kanske. Anta inte implementationen bara för att ett affärsbegrepp låter som ett Salesforce-objekt. Det är därför vi byggde den logiska modellen först: den ger oss något att testa Salesforce-designen mot.
En affärsentitet betyder inte automatiskt ett anpassat objekt
Section titled “En affärsentitet betyder inte automatiskt ett anpassat objekt ”Här är en fälla jag vill att admins undviker: ”Vi identifierade elva entiteter, så vi behöver elva anpassade objekt.” Nej. En logisk entitet säger oss att affärsbegreppet spelar roll. Den bestämmer inte hur Salesforce måste lagra det. Ett begrepp kan bli ett standardobjekt, ett anpassat objekt, en relation mellan objekt, ett fält eller några fält, ett värde som förvaltas i konfigurationen, eller data som bor helt utanför Salesforce (Steve Truckings leveransfoton är en bra kandidat för det). Den fysiska modellen är där de valen görs, och det är precis därför vi inte gjorde dem vid det första samtalet.
Attribut blir fysiska fält
Section titled “Attribut blir fysiska fält ”Samma övergång sker med attributen. Vår logiska lastbil har enhetsnummer, VIN, märke, modell, årsmodell, registreringsnummer och status. Nu bestämmer vi hur de fysiskt ska finnas: vilket objekt som äger dem, vilka fälttyper de använder, vilka som är obligatoriska, vilka som måste vara unika, vilka som är externa ID:n, vilka som behöver validering, vilka som härleds i stället för att lagras, och vilka som är känsliga. På logisk nivå frågade vi vad en lastbil betyder. På fysisk nivå frågar vi hur Salesforce ska representera en lastbil. Olika frågor.
Relationer blir plattformsbeslut
Section titled “Relationer blir plattformsbeslut ”All tid vi lade på relationer lönar sig här. Vi vet redan om var och en är en-till-en, en-till-många eller många-till-många, obligatorisk eller valfri, och om dess historik spelar roll. Nu bestämmer vi hur Salesforce implementerar den: en lookup-relation, en master-detail-relation eller ett kopplingsobjekt i Salesforce (Salesforce Junction Object), och kanske en koppling med egna attribut, eftersom, som vi upptäckte, själva relationen kan ha en affärsmässig betydelse.
Tänk tillbaka på teamtilldelningen. Vi kunde ha börjat det här kapitlet med att säga: ”Vi skapar ett kopplingsobjekt i Salesforce mellan team och lastbil.” Titta på vad vi då skulle ha hoppat över: varför relationen finns, om den behöver ett datum och en rutt, om den har en status, och om ett skadeärende några veckor senare behöver dess historik. De affärsfrågorna säger oss vad en teamtilldelning är. Först då ska vi bestämma hur Salesforce bygger den, och om Salesforce redan har något som gör jobbet.
Rita nu den fysiska modellen
Section titled “Rita nu den fysiska modellen ”Diagrammet ändras igen. Den konceptuella modellen visade affärsbegrepp och enkla linjer. Den logiska modellen lade till attribut, nycklar, kardinalitet och entiteterna som gömde sig i relationerna. Nu börjar den fysiska modellen se ut som Salesforce: standardobjekt, anpassade objekt, fält, relationstyper och det som bor utanför plattformen.
Jag vill att du ska kunna lägga de tre diagrammen sida vid sida och se förloppet: inte tre orelaterade diagram, utan samma verksamhet på tre nivåer.
Några ord om hur jag ritar de här, för layouten är en del av budskapet. Jag lägger det primära objektet i mitten, en bit ned. Om det har föräldraobjekt lägger jag dem en bit ovanför, så att du läser modellen uppifrån och ned, från vänster till höger, så som verksamheten tänker på den. Referensdata hamnar vid sidan. Färg betyder också något: jag gör alltid Salesforce blått, och jag väljer en färg för företagets egna system, oftast grönt, för grönt är en trevlig, vänlig färg. Jag använder inte rött, och gula färger är lite skarpa. När en modell är upplagd så, då sjunger den för mig. Många av diagrammen du hittar handlar egentligen om platshantering: hur parkerar jag alla mina bilar i mitt överfulla garage? Jag målar hellre en logisk bild som hjärnan kan greppa.
Den fysiska modellen måste respektera plattformen
Section titled “Den fysiska modellen måste respektera plattformen ”Salesforce är ingen generisk relationsdatabas. Den har åsikter om relationer, ägarskap, säkerhet och rapportering. Den har gränser, frågebeteende och automatisering, och en arkitektur som påverkar hur en modell beter sig i stor skala. Så en logisk modell som ser perfekt ut på en whiteboard kan behöva ändras när den blir fysisk. Det är inte Salesforce som står i vägen. Det betyder att plattformen har en form, och bra arkitekter förstår den formen. Nästa kapitel handlar om precis det.
Ibland kommer den fysiska modellen också medvetet att skilja sig från den rena logiska modellen på grund av denormaliseringsbesluten vi fattade i modul 5. Det är helt okej, så länge vi kan förklara varför.
Designa inte från Setup
Section titled “Designa inte från Setup ”Det finns en vana jag vill att du gör dig av med om du har den: att börja din dataarkitektur i Setup → Object Manager → New Custom Object och räkna ut modellen under tiden. Salesforce gör det otroligt enkelt att skapa saker; det är en av dess styrkor, och ett av skälen till att svaga datamodeller uppstår så snabbt. Några klick och du har ett objekt, några till och du har fält och en relation. Sedan kommer data, flöden byggs, rapporter skapas, integrationer blir beroende av det, och objektet du skapade på fem minuter blir väldigt dyrt att ändra. Det är reversibilitetstestet från kapitel 1. Så innan du klickar på New Custom Object, rita modellen.
Fysiskt betyder inte permanent
Section titled “Fysiskt betyder inte permanent ”Det finns ett annat skäl till att jag håller de tre modellerna separata: tekniken förändras. I dag bor en del av Steve Truckings data på Salesforce core. I morgon kan en del av dem bo i Data 360, ett datalager eller ett system vi inte har valt än, och AI-assistenten behöver sin egen representation. Den fysiska arkitekturen kan ändras, medan affärsbegreppen förblir anmärkningsvärt stabila: detaljhandelspartner, leveranser och mottagare finns fortfarande. Det är det som gör den logiska modellen värdefull. Den är en hållbar beskrivning av verksamheten som inte är bunden till dagens implementation.
Vad en arkitekt bestämmer här
Section titled “Vad en arkitekt bestämmer här ”När jag gör en logisk modell till en fysisk modell i Salesforce bestämmer jag:
- Vilka affärsentiteter som motsvaras av standardfunktioner i Salesforce, och vilka som behöver anpassade objekt eller en annan representation.
- Hur logiska attribut blir fysiska fält, och hur relationer implementeras på plattformen.
- Var medveten denormalisering hör hemma i den fysiska designen.
- Vilka data som hör hemma i Salesforce, och vilka som hör hemma någon annanstans.
- Vilka egenskaper hos plattformen som kräver att den fysiska modellen skiljer sig från den logiska.
Viktigast av allt: jag vill kunna spåra varje beslut bakåt. Om du pekar på något i min fysiska modell och frågar ”Varför finns det där?” ska jag kunna ta dig tillbaka genom den logiska modellen och den konceptuella modellen till något som verksamheten faktiskt behöver: verksamhet → konceptuell → logisk → fysisk.
Bortom provet: vad AI förändrar. AI kan nu ta ett kravdokument hela vägen till Salesforce-objekt och fält i ett enda hopp. Det gör ordningen viktigare, inte mindre viktig: om den hoppar från krav till konfiguration, be den visa vad som hände däremellan: vad den bestämde var en entitet, vilka nycklar den valde, vilka relationer den antog och var den denormaliserade. Det är arkitekturbeslut, och arkitekten behöver fortfarande se dem.
Vi började det här kapitlet vid ett första samtal, där vi lyssnade efter substantiv, och vi avslutar det med en fysisk modell som vi kan spåra tillbaka till verksamheten. Nu när vi har valt att bygga på Salesforce går nästa fråga djupare: vilken sorts dataplattform bygger vi egentligen på?
Utforska vidare
Section titled “Utforska vidare ”- Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (på engelska, kontrollerad 2026-10-02): ”konfigurera föräldra-barn-relationer med högst 10 000 barn per föräldrapost.” En riktlinje om data skew, ingen hård gräns; kapitel 7 går djupare.
- Roll-Up Summary Field (opens in a new tab), Salesforce Help (på engelska, kontrollerad 2026-10-12): ett sammanställningsfält räknar eller summerar detaljposter via en master-detail-relation.