Design den fysiske model i Salesforce

🌐 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 10 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Hold data konsistente · Næste: studieguiden til kapitlet, og derefter det næste kapitel, Forstå virksomhedens data

Spørgsmålet, dette modul besvarer: Hvordan gør vi vores logiske model til en arkitektur i Salesforce?

Hele dette kapitel har været ét langt argument for, at platformen har en form: standardobjekter og brugerdefinerede objekter, steder, hvor data kan bo, felttyper, relationer, ejerskab, licenser, konsistensregler, lagerplads og skala. Hver af dem kan ændre, hvordan den logiske model fra kapitel 2 bliver bygget. Lad os nu samle det hele på ét udsnit af Steve Trucking.

Ét udsnit, ikke hele virksomheden. En fejl, jeg ser arkitekter begå, er at prøve at løse hele virksomheden i ét diagram. Jeg vil have noget, vi kan ræsonnere om: en detailpartner sender et manifest, Steve Trucking leverer det, der står på det, og vi gemmer det, vi har brug for om hver levering. Så træffer vi de fysiske beslutninger én ad gangen. Det fulde design er kontrolpunktet for del 1.

Start med det, vi allerede ved

Kapitel 2 lavede det konceptuelle arbejde: detailpartner (Retail Partner), modtager (Recipient), manifest (Manifest), levering (Delivery), leveringslinje (Delivery Item), typen af stop, team (Crew), lastbil (Truck), distributionscenter (Distribution Center) og fotos. Vi navngav relationerne og spurgte, hvad de betyder. Det gentager jeg ikke. Spørgsmålet nu er, hvordan de begreber lever i Salesforce. Ét faktum fra briefen betyder noget med det samme: Steve Trucking kører allerede Field Service til aftaler, teams og mobilappen.

Detailpartner: opfind ikke en konto

En detailpartner er en virksomhed, Steve Trucking arbejder for. Salesforce har allerede et objekt, der er designet til virksomheder: konto (Account). Rent match. Så ingen Retail_Partner__c, bare fordi forretningen siger »partner«. Det er en konto med en posttype for detailpartnere, så den kan skelnes fra andre organisationer, og med den følger kontrakter, sager, kontakter (Contacts) til DC-lederne og portaladgang for de kontakter. Nem beslutning. Det er ikke alle.

Partnerens ordrenummer er ikke vores id

Hver detailpartner sender sine egne referencer. Én partners ordre ser ud som 8843119, en andens som A-984732. De numre betyder noget, men hvis er de? Partnerens. Salesforce har sit eget post-id, og partneren har den reference, den bruger, når den taler med os. Begge kan findes; det er kapitel 2’s »én ting, flere identifikatorer«.

Så partnerens reference bliver et External ID, som integrationen bruger til at matche opdateringer. Og fordi to partnere kan bruge det samme nummer, er nøglen partneren plus referencen, ikke referencen alene. Gør ikke en partners nummer til leveringens universelle id, bare fordi det kom først, og lad ikke en integration søge i et tekstfelt, hver gang den skal finde en post.

Levering: kig på moderskibet

Her er det fristende at oprette Delivery__c. Forretningen sagde »levering«, så vi skal have et leveringsobjekt. Det er præcis det, jeg ikke vil have, at du gør først. Kig på moderskibet, som vi gjorde i modul 2. Hvad har Salesforce allerede til arbejde, der udføres på en adresse, med en livscyklus, linjer, planlægning og et team ude i marken? Field Service’ arbejdsordre (Work Order): Salesforce beskriver den som field service-arbejde, der skal udføres for en kunde (WorkOrder (opens in a new tab)). Det planlagte besøg og dets tidsvindue er serviceaftalen (Service Appointment), og det er den, disponeringen planlægger, og teamets app viser.

Så levering → arbejdsordre. Ikke fordi ordene passer; det gør de ikke. Men fordi adfærden passer til den platformsfunktion, vi allerede betaler for og har tænkt os at bruge. Et standardobjekt behøver ikke at dele forretningens ordforråd. Det skal repræsentere begrebet korrekt.

Click to enlarge

Trin 1 af 4: moderskibet. Hvert kort er forretningsbegrebet med dets Salesforce-objekt nedenunder.

Men standardobjekter kommer med bagage

Den anden halvdel: arbejdsordren er ikke gratis. Den kommer med Field Service-licenser, sine egne relationer, sikkerhedsadfærd, påkrævede felter, automatisering og livscyklus, og andre dele af platformen forventer, at den opfører sig på en bestemt måde. Vi vælger den, fordi matchet er rent, og fordi vi bruger det, der er bygget omkring den. Hvis Steve Trucking ikke ville have noget af Field Service, og modellen kæmpede imod processen ved hvert skridt, ville jeg tænke mig om igen. Arkitekturen er matchet, ikke etiketten.

Leveringslinjer: følg modellen

Når levering er en arbejdsordre, så kig på resten af den model, før du opfinder noget. En arbejdsordrelinje (Work Order Line Item) er en delopgave på en arbejdsordre (WorkOrderLineItem (opens in a new tab)): køleskabet, installationen, bortkørslen af det gamle. Så leveringslinje → arbejdsordrelinje. Læg mærke til, at den første beslutning formede den anden. Vi vælger ikke et objekt til hver enhed for sig. Tag en model i brug, og forstå resten af den, før du bygger brugerdefinerede strukturer omkring den.

Hvilken type stop er det her?

Hos Steve Trucking er et stop enten kun levering, levering med installation eller levering med bortkørsel, og hver type har sin egen varighed, sine egne krav til teamets færdigheder og sin egen installationstjekliste. I kapitel 2 besluttede vi, at det er en enhed, ikke en etiket. Field Service har allerede en: arbejdstype (Work Type), en skabelon for en type arbejde, der kan bruges på arbejdsordrer og linjer (WorkType (opens in a new tab)). Så type stop → arbejdstype. Igen ikke fordi der findes noget, der hedder Work Type, men fordi begrebet og adfærden passer sammen.

Click to enlarge

Trin 2 af 4: følg modellen. Linjer og arbejdstype følger med arbejdsordren.

Manifest: nu vil jeg have et brugerdefineret objekt

Findes der et standardobjekt til »partnerens liste for tirsdag på DC’et i Phoenix«? Ikke rigtig, og jeg vil ikke tvinge det ind i et objekt, der ikke har noget med det at gøre, bare for at kunne sige, at vi holdt os til standard. Manifest → Manifest__c. Det er modtagelsesenheden: hvor det kom fra (en fil, en API-batch), hvornår, dets status og totaler, og hvad der bliver sammenlignet, når en partner sender det igen samme dag. Hver linje i manifestet bliver til en arbejdsordre, der peger tilbage på det.

Brugerdefineret er ikke en fiasko. Det er det, platformen giver os, når et begreb ikke har et rent standardhjem. Fejlen er ikke at oprette et brugerdefineret objekt; det er at oprette et uden at tjekke, om platformen allerede har begrebet.

Click to enlarge

Trin 3 af 4: det ene brugerdefinerede objekt, hvor intet standardobjekt passer.

Fotos: bare fordi Salesforce kan gemme det, betyder det ikke, at det skal

»Vi skal have leveringsfotoene i Salesforce.« Hvad betyder »i Salesforce«? Brugerne skal kunne se dem fra Salesforce, ja. Betyder det, at billedfilerne skal bo i core-lagerpladsen? Ikke nødvendigvis. Tæl nullerne: omkring fire fotos pr. levering, flere med installationer, ved en million leveringer om året, giver fire til fem millioner fotos om året, og leveringerne vokser 30 % om året.

Så min udgangsposition er: gør ikke core-org’en til et kæmpe fotoarkiv, fordi brugerne skal have adgang til fotos. Filerne hører hjemme i lagerplads, der er bygget til den volumen, uden for core, og Salesforce gemmer det, den skal bruge for at finde og vise dem: en reference, et antal eller en lille indekspost pr. foto og et flag for, at de påkrævede installationsfotos er komplette. Adgang til data og det sted, hvor dataene fysisk bor, er to forskellige spørgsmål. Det er modul 4, der kommer tilbage.

Felter: gør betydningen synlig

Arbejdsordren skal have felter: partnerens reference, leveringsvinduet, det faktiske leveringstidspunkt, status og noter som »portkode« eller »hund i haven«. Jeg vil ikke gøre det her til et feltkatalog; det gjorde modul 6. Stil spørgsmålene for hvert felt: hvad det betyder, hvem der ejer det, om det ændrer sig, om det er en identifikator, et kontrolleret ordforråd, gemt eller afledt, følsomt. Partnerens reference er External ID’et, så dens unikhed er en del af integrationskontrakten, ikke bare et afkrydsningsfelt. Det faktiske leveringstidspunkt er et øjeblik, så dato/tid. Status styrer adfærd, så en kontrolleret liste, aldrig fritekst. Og leveringsnoter om en persons hjem er persondata, så de bliver klassificeret. Hvert felt kan spores tilbage til en betydning.

Relationer: forbind ikke bare kasserne

Konto til arbejdsordre, arbejdsordre til dens linjer, manifest til arbejdsordre, arbejdstype, der beskriver stoppet. Stil så spørgsmålene fra modul 7 for hver linje: kan barnet eksistere alene, hvem ejer det, nedarves adgangen, kan det flytte, hvad sker der ved sletning, hvor mange børn kan hobe sig op? Alle arbejdsordrer under en håndfuld detailpartnerkonti betyder hundredtusinder af børn pr. forælder: et skew-spørgsmål, vi besvarer i del 2. Og for Field Service’ standardrelationer: tjek, hvordan Salesforce allerede har bygget dem, i stedet for at gå ud fra, at de passer med det, vi selv ville have designet. Når du tager en standardmodel i brug, tager du de beslutninger i brug, som Salesforce traf inde i den. Forstå dem, før du bygger ovenpå.

Ejerskab og modtageren: lad ikke standardindstillingen bestemme

To beslutninger, som en standardindstilling gladelig ville træffe for os.

Hvem ejer en levering? Det besvarede vi i modul 8, og det overføres direkte til arbejdsordren: ejerskab styrer ikke nogens adgang her, så integrationsbrugeren ejer de arbejdsordrer, den opretter. Disponenterne ser deres distributionscenters, teamene ser deres ruters, og hver detailpartner ser sine egne gennem portalen, alt sammen via deling, ikke ejerskab. Integrationsbrugeren har ingen rolle og holdes uden for de offentlige grupper, vores delingsregler bruger, for med 3.300 om dagen passerer den 10.000 poster på tre dage. Og vi skriver ned, hvad der sker, hvis den bruger nogensinde bliver udskiftet.

Hvad er modtageren? En kontakt? En personkonto? Noget, der kun gemmes på leveringen? Det afhænger af, om Steve Trucking overhovedet har en relation til de mennesker (de er detailpartnernes kunder), om én partner nogensinde må se en andens, hvor længe deres persondata må gemmes, og af skalaen: omkring en million nye modtagere om året. Vi har ikke alt det endnu, og det er helt i orden. Nogle gange er det rigtige svar: vi ved ikke nok endnu. Skriv spørgsmålet ned, og gå ud og hent informationen; begrav ikke usikkerheden i et brugerdefineret objekt. Vi besvarer det ved kontrolpunktet for del 1, når kapitel 4 til 6 har givet os billedet af virksomheden og masterdataene.

Konsistens: beskyt modellen i det rigtige lag

Stigen fra modul 9 gælder: partnerens reference er et unikt External ID, så et manifest, der sendes igen, laver upsert i stedet for dubletter; status er en begrænset valgliste; det faktiske leveringstidspunkt er kun påkrævet, når status siger Leveret; et installationsstop kan ikke lukkes uden sin tjekliste og sine fotos. Ikke ét kæmpe flow. Hver regel på sit eget trin.

Hvor hver del bor

Én gennemgang mere af udsnittet, med spørgsmålet fra modul 4: hvor bor hver enkelt del af dataene? I mit undervisningsmateriale er det ét slide, logisk over for fysisk: de logiske enheder fra kapitel 2, og hvor hver af dem fysisk lander: på core, som et sObject (__c, hvis det er brugerdefineret) eller et big object (__b), eller uden for core, som et eksternt objekt (__x) eller data, der aldrig kommer ind i Salesforce.

• På core, i daglig brug: kontoen, arbejdsordrerne og deres linjer, serviceaftalerne, arbejdstyperne og Manifest__c.
• På core, arkiveret: leveringer, der er mere end tre år gamle, flyttes til Delivery History, et big object, og er der stadig til reklamationssager, ude i skuret.
• Refereret: detailpartnerens egne ordredetaljer bliver i partnerens system; vi gemmer partnerens reference som et External ID og når resten gennem et eksternt objekt eller integrationen, når nogen har brug for det.
• Uden for core: fotoene, i lagerplads bygget til millioner af billeder, med et link fra arbejdsordren.

Det er den fysiske model: ikke kun hvilket objekt, men hvilket hjem.

Se nu på hele udsnittet

• Detailpartner → konto med en posttype for detailpartnere; DC-ledere som kontakter.
• Levering → arbejdsordre i Field Service, planlagt gennem en serviceaftale.
• Leveringslinje → arbejdsordrelinje.
• Type stop → arbejdstype.
• Manifest → det brugerdefinerede Manifest__c.
• Partnerreference → External ID på arbejdsordren, unikt pr. partner.
• Fotos → gemt uden for core; Salesforce gemmer referencen og flaget for fuldstændighed.
• Leveringshistorik → arkiveret i et big object efter tre år.
• Ejerskab → integrationsbrugeren, med adgang via deling (modul 8).
• Modtager → åbent, til kontrolpunktet for del 1.

Click to enlarge

Trin 4 af 4: hele udsnittet, på core, arkiveret og uden for core. Hver linje er et lookup: Salesforce byggede Field Service på lookups, og vi tager deres beslutninger i brug sammen med det.

Diagrammet er ikke arkitekturen

Jeg kan give dig det diagram, og det er ikke nok. Arkitekturen er ræsonnementet bag det. Hvorfor en konto? En virksomhed med rent match. Hvorfor arbejdsordre og ikke Delivery__c? Leveringen opfører sig som arbejde i marken, og Field Service er der allerede. Hvorfor et brugerdefineret manifest? Intet rent standardhjem. Hvorfor er fotos ikke bare Files? Volumen og lagerøkonomi. Hvorfor et External ID? Et andet system har brug for et stabilt id på tværs af grænsen. Hvorfor ejer integrationsbrugeren arbejdsordrerne? Ejerskab styrer ikke adgang her, og det holder revisionssporet ærligt. Hvorfor er modtageren stadig åben? Vi har ikke besvaret spørgsmål nok endnu. Linjerne er resultatet; beslutningerne skabte dem.

Så her er den vane, jeg gerne vil have, at du tager med dig fra kapitel 3. Peg på hvad som helst i en fysisk model, og spørg hvorfor? Hvorfor dette objekt, denne type, denne relation, denne ejer, dette sted, denne regel? Du skal kunne spore svaret tilbage: fra konfigurationen til den fysiske model, til den logiske model, til forretningskravet. Hvis du ikke kan det, har nogen designet ud fra Setup.

Og du har nok lagt mærke til de tal, vi ikke har regnet helt igennem: leveringer pr. partner, linjer, fotos, opbevaring, arkivering. Godt. Spørg efter antallet af nuller, før du låser et design fast: en model, der fungerer smukt ved halvtreds tusind poster, kan opføre sig helt anderledes ved fem hundrede millioner. Det er del 2.

Ud over eksamen: hvad AI ændrer. Giv en AI Steve Truckings brief, og den producerer et skema på få sekunder: konto, arbejdsordre, brugerdefinerede objekter, felter, ja endda deployment-metadata. Det er en fantastisk accelerator, og det er ikke gennemgangen. Arkitektens job flytter sig til at tjekke koblingerne og deres konsekvenser: match, licenser, ejerskab, livscyklus, skala, id’er, sikkerhed og det, der bliver uden for platformen. AI er raketboosteren; den fortæller dig ikke, om du peger i den rigtige retning.

Hvad en arkitekt beslutter her

• Hvordan hvert forretningsbegreb kobles til Salesforce: et standardobjekt, et brugerdefineret objekt eller noget uden for core.
• Hvilke identifikatorer, felter og relationer der implementerer forretningens betydning uden stille og roligt at ændre den.
• Hvilken platformsadfærd og hvilke licenser der følger med en standardmodel, du tager i brug.
• Hvilke beslutninger om ejerskab, livscyklus, konsistens, lagerplads og skala der skal træffes, før designet er færdigt.
• Hvilke spørgsmål der udtrykkeligt forbliver åbne i stedet for at blive gemt bag et tilfældigt implementeringsvalg.

I starten af dette kapitel spurgte vi, hvordan modellen skulle leve i Salesforce. Det er dataarkitektur i Salesforce: ikke at oprette objekter, ikke at lære Setup udenad, ikke at tegne pænere kasser, men bevidst at tilpasse forretningsmodellen til platformens form. Hver struktur er en forpligtelse. Lav dem, du kan forklare.

Læs mere

• Salesforce Developers, Object Reference: WorkOrder (opens in a new tab), WorkOrderLineItem (opens in a new tab) og WorkType (opens in a new tab) (på engelsk, kontrolleret 2026-10-02).
• Steve Truckings brief (på engelsk).