Design den fysiske modellen i Salesforce

🌐 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)

Bildet er laget med KI

Oversatt med KI. Fellesskapet har ikke gjennomgått oversettelsen ennå. Les på engelsk

Modul 10 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Hold data konsistente · Neste: studieguiden for kapitlet, og så neste kapittel, Forstå virksomhetens data

Spørsmålet denne modulen besvarer: Hvordan gjør vi den logiske modellen vår om til en arkitektur i Salesforce?

Hele dette kapitlet har vært ett langt argument for at plattformen har en form: standardobjekter og egendefinerte objekter, steder data kan bo, felttyper, relasjoner, eierskap, lisenser, konsistensregler, lagring og skala. Hver av dem kan endre hvordan den logiske modellen fra kapittel 2 blir bygget. Nå setter vi det sammen på én bit av Steve Trucking.

Én bit, ikke hele selskapet. En feil jeg ser arkitekter gjøre, er å prøve å løse hele virksomheten i ett diagram. Jeg vil ha noe vi kan resonnere om: en detaljhandelspartner (Retail Partner) sender et manifest, Steve Trucking leverer det som står på det, og vi tar vare på det vi trenger om hver levering. Så tar vi de fysiske beslutningene én om gangen. Det fullstendige designet er kontrollpunktet for del 1.

Start med det vi allerede vet

Kapittel 2 gjorde det konseptuelle arbeidet: detaljhandelspartner, mottaker (Recipient), manifest, levering (Delivery), leveringslinje (Delivery Item), typen stopp, team (Crew), lastebil (Truck), distribusjonssenter (DC), bilder. Vi navnga relasjonene og spurte hva de betyr. Det gjentar jeg ikke. Spørsmålet nå er hvordan disse begrepene lever i Salesforce. Ett faktum fra briefen betyr noe med en gang: Steve Trucking kjører allerede Field Service for avtaler, team og mobilappen.

Detaljhandelspartner: ikke finn opp en konto

En detaljhandelspartner er et selskap Steve Trucking jobber for. Salesforce har allerede et objekt laget for selskaper: konto (Account). Ren passform. Så ingen Retail_Partner__c bare fordi virksomheten sier «partner». Det er en konto, med en posttype for detaljhandelspartnere som skiller den fra andre organisasjoner, og med den følger kontrakter, saker, kontakter (Contacts) for DC-lederne og portaltilgang for de kontaktene. Enkel beslutning. Ikke alle er det.

Partnerens ordrenummer er ikke vår identifikator

Hver detaljhandelspartner sender sine egne referanser. Én partners ordre ser ut som 8843119, en annens som A-984732. De numrene betyr noe, men hvem sine er de? Partnerens. Salesforce har sin egen post-ID, og partneren har referansen den bruker når den snakker med oss. Begge kan finnes; det er «én ting, flere identifikatorer» fra kapittel 2.

Så partnerens referanse blir en External ID som integrasjonen bruker til å matche oppdateringer. Og fordi to partnere kan bruke samme nummer, er den unike nøkkelen partneren pluss referansen, ikke referansen alene. Ikke gjør en partners nummer til leveringens universelle ID fordi det kom først, og ikke la en integrasjon søke i et tekstfelt hver gang den skal finne en post.

Levering: se til moderskipet

Her er det fristende å lage Delivery__c. Virksomheten sa «levering», så vi trenger et leveringsobjekt. Det er akkurat det jeg ikke vil at du skal gjøre først. Se til moderskipet, slik vi gjorde i modul 2. Hva har Salesforce allerede for arbeid som utføres på et sted, med en livssyklus, linjer, planlegging og et team ute i felten? Field Service sin arbeidsordre (Work Order): Salesforce beskriver den som feltservicearbeid som skal utføres for en kunde (WorkOrder (opens in a new tab)). Det planlagte besøket og tidsvinduet er serviceavtalen (Service Appointment), og det er den utkjøringen planlegger og teamets app viser.

Så levering → arbeidsordre. Ikke fordi ordene stemmer; det gjør de ikke. Men fordi atferden stemmer med plattformfunksjonen vi allerede betaler for og har tenkt å bruke. Et standardobjekt trenger ikke dele virksomhetens ordforråd. Det må representere begrepet riktig.

Click to enlarge

Steg 1 av 4: moderskipet. Hvert kort er forretningsbegrepet, med Salesforce-objektet under.

Men standardobjekter kommer med bagasje

Den andre halvdelen: arbeidsordren er ikke gratis. Den tar med seg lisenser for Field Service, egne relasjoner, sikkerhetsatferd, obligatoriske felt, automatisering og livssyklus, og andre deler av plattformen forventer at den oppfører seg på en bestemt måte. Vi velger den fordi passformen er ren og fordi vi bruker det som er bygget rundt den. Hvis Steve Trucking ikke ville ha noe av Field Service, og modellen kjempet mot prosessen ved hver sving, ville jeg tenkt meg om igjen. Arkitekturen er passformen, ikke merkelappen.

Leveringslinjer: følg modellen

Når levering er en arbeidsordre, se på resten av den modellen før du finner opp noe. En arbeidsordrelinje (Work Order Line Item) er en deloppgave på en arbeidsordre (WorkOrderLineItem (opens in a new tab)): kjøleskapet, installasjonen, bortkjøringen. Så leveringslinje → arbeidsordrelinje. Legg merke til at den første beslutningen formet den andre. Vi velger ikke et objekt for hver entitet for seg. Ta i bruk en modell, og forstå resten av den før du bygger egendefinerte strukturer rundt den.

Hva slags stopp er dette?

Hos Steve Trucking er et stopp enten bare levering, levering med installasjon eller levering med bortkjøring, og hver type har sin egen varighet, sine egne krav til teamets ferdigheter og sin egen sjekkliste for installasjon. I kapittel 2 bestemte vi at det er en entitet, ikke en merkelapp. Field Service har allerede en: arbeidstype (Work Type), en mal for en type arbeid som kan brukes på arbeidsordrer og linjer (WorkType (opens in a new tab)). Så type stopp → arbeidstype. Igjen, ikke fordi det finnes noe som heter Work Type, men fordi begrepet og atferden stemmer overens.

Click to enlarge

Steg 2 av 4: følg modellen. Linjene og arbeidstypen følger med arbeidsordren.

Manifest: nå vil jeg ha et egendefinert objekt

Finnes det et standardobjekt for «partnerens liste for tirsdag ved DC-et i Phoenix»? Egentlig ikke, og jeg skal ikke presse det inn i et objekt som ikke har noe med det å gjøre bare for å kunne si at vi holdt oss til standard. Manifest → Manifest__c. Det er mottaksenheten: hvor det kom fra (en fil, en API-batch), når, status og totaler, og hva som sammenlignes når en partner sender det på nytt samme dag. Hver manifestlinje blir en arbeidsordre som lenker tilbake til det.

Egendefinert er ikke et nederlag. Det er det plattformen gir oss når et begrep ikke har noe rent standardhjem. Feilen er ikke å lage et egendefinert objekt; det er å lage et uten å sjekke om plattformen allerede har begrepet.

Click to enlarge

Steg 3 av 4: det ene egendefinerte objektet, der ingen standardobjekter passer.

Bilder: at Salesforce kan lagre det, betyr ikke at det bør

«Vi trenger leveringsbildene i Salesforce.» Hva betyr «i Salesforce»? Brukerne må kunne se dem fra Salesforce, ja. Betyr det at bildefilene må bo i lagringen på core? Ikke nødvendigvis. Tell nullene: rundt fire bilder per levering, flere med installasjoner, med en million leveringer i året, blir fire til fem millioner bilder i året, og leveringene vokser 30 % i året.

Så utgangspunktet mitt er: ikke gjør core-orgen om til et gigantisk bildearkiv fordi brukerne trenger tilgang til bilder. Filene hører hjemme i lagring bygget for det volumet, utenfor core, mens Salesforce beholder det den trenger for å finne og vise dem: en referanse, et antall eller en liten indekspost per bilde, og et flagg som sier at de påkrevde installasjonsbildene er komplette. Tilgang til data og hvor dataene fysisk bor, er to forskjellige spørsmål. Det er modul 4 som kommer tilbake.

Felt: gjør meningen synlig

Arbeidsordren trenger felt: partnerens referanse, leveringsvinduet, det faktiske leveringstidspunktet, status, notater som «portkode» eller «hund i hagen». Jeg skal ikke gjøre dette om til en feltkatalog; det gjorde modul 6. Still spørsmålene for hvert felt: hva det betyr, hvem som eier det, om det endrer seg, om det er en identifikator, et kontrollert ordforråd, lagret eller avledet, sensitivt. Partnerens referanse er External ID, så det at den er unik, er en del av integrasjonskontrakten, ikke bare en avkrysningsboks. Det faktiske leveringstidspunktet er et øyeblikk, altså Date/Time. Status styrer atferd, altså en kontrollert liste, aldri fritekst. Og leveringsnotater om noens hjem er personopplysninger, så de blir klassifisert. Hvert felt kan spores tilbake til en mening.

Relasjoner: ikke bare koble sammen boksene

Konto til arbeidsordre, arbeidsordre til linjene sine, manifest til arbeidsordre, arbeidstype som beskriver stoppet. Så stiller du spørsmålene fra modul 7 for hver linje: kan barnet finnes alene, hvem eier det, arves tilgangen, kan det flyttes, hva skjer ved sletting, hvor mange barn kan hope seg opp? Alle arbeidsordrene under en håndfull kontoer for detaljhandelspartnere betyr hundretusenvis av barn per forelder: et skew-spørsmål vi svarer på i del 2. Og for standardrelasjonene i Field Service: sjekk hvordan Salesforce allerede har bygget dem i stedet for å anta at de er slik vi ville designet dem. Når du tar i bruk en standardmodell, tar du i bruk beslutningene Salesforce tok inni den. Forstå dem før du bygger oppå.

Eierskap og mottakeren: ikke la standardvalget bestemme

To beslutninger som et standardvalg gjerne ville tatt for oss.

Hvem eier en levering? Det svarte vi på i modul 8, og det overføres rett til arbeidsordren: eierskap styrer ikke noens tilgang her, så integrasjonsbrukeren eier arbeidsordrene den lager. Koordinatorene ser sitt distribusjonssenters, teamene ser rutenes sine, og hver detaljhandelspartner ser sine egne gjennom portalen, alt gjennom deling, ikke eierskap. Integrasjonsbrukeren har ingen rolle og holdes utenfor de offentlige gruppene delingsreglene våre bruker, for med 3 300 om dagen passerer den 10 000 poster på tre dager. Og vi skriver ned hva som skjer hvis den brukeren noen gang byttes ut.

Hva er mottakeren? En kontakt? En personkonto? Noe som bare lagres på leveringen? Det avhenger av om Steve Trucking i det hele tatt har et forhold til disse menneskene (de er detaljhandelspartnernes kunder), om én partner noen gang kan få se en annens, hvor lenge personopplysningene deres kan oppbevares, og skalaen: rundt en million nye mottakere i året. Alt det har vi ikke ennå, og det er greit. Noen ganger er det riktige svaret vi vet ikke nok ennå. Skriv ned spørsmålet og gå og skaff informasjonen; ikke begrav usikkerheten i et egendefinert objekt. Vi svarer på det ved kontrollpunktet for del 1, etter at kapittel 4 til 6 har gitt oss bildet av virksomheten og masterdataene.

Konsistens: beskytt modellen på riktig lag

Stigen fra modul 9 gjelder: partnerens referanse er en External ID, unik, så et manifest som sendes på nytt, gjør en upsert i stedet for å lage duplikater; status er en begrenset liste; det faktiske leveringstidspunktet er obligatorisk først når statusen sier Levert; et installasjonsstopp kan ikke lukkes uten sjekklisten og bildene. Ikke én gigantisk flow. Hver regel på sitt eget trinn.

Hvor hver del bor

En runde til over biten, med spørsmålet fra modul 4: hvor bor hver del av dataene? I kursdekket mitt er det én slide, logisk mot fysisk: de logiske entitetene fra kapittel 2, og hvor hver av dem havner fysisk: på core, som et sObject (__c hvis det er egendefinert) eller et big object (__b), eller utenfor core, som et eksternt objekt (__x) eller data som aldri kommer inn i Salesforce i det hele tatt.

• På core, i daglig bruk: kontoen, arbeidsordrene og linjene deres, serviceavtalene, arbeidstypene, Manifest__c.
• På core, arkivert: leveringer eldre enn tre år flyttes til Delivery History, et big object, fortsatt der for reklamasjoner, ute i boden.
• Referert: detaljhandelspartnerens egne ordredetaljer blir i partnerens system; vi beholder partnerens referanse som en External ID, og når resten gjennom et eksternt objekt eller integrasjonen når noen trenger det.
• Utenfor core: bildene, i lagring bygget for millioner av bilder, med en lenke fra arbeidsordren.

Det er den fysiske modellen: ikke bare hvilket objekt, men hvilket hjem.

Se nå på hele utsnittet

• Detaljhandelspartner → konto, med en posttype for detaljhandelspartnere; DC-lederne som kontakter.
• Levering → arbeidsordre i Field Service, planlagt gjennom en serviceavtale.
• Leveringslinje → arbeidsordrelinje.
• Type stopp → arbeidstype.
• Manifest → egendefinert Manifest__c.
• Partnerreferanse → External ID på arbeidsordren, unik per partner.
• Bilder → lagret utenfor core; Salesforce beholder referansen og flagget for fullstendighet.
• Leveringshistorikk → arkivert til et big object etter tre år.
• Eierskap → integrasjonsbrukeren, med tilgang gjennom deling (modul 8).
• Mottaker → åpent, til kontrollpunktet for del 1.

Click to enlarge

Steg 4 av 4: hele biten, på core, arkivert og utenfor core. Hver linje er en lookup: Salesforce bygget Field Service på lookup-relasjoner, og vi tar i bruk beslutningene deres sammen med den.

Diagrammet er ikke arkitekturen

Jeg kan gi deg det diagrammet, og det er ikke nok. Arkitekturen er resonnementet bak det. Hvorfor konto? Et selskap med ren passform. Hvorfor arbeidsordre og ikke Delivery__c? Leveringen oppfører seg som feltarbeid, og Field Service er allerede på plass. Hvorfor et egendefinert manifest? Ikke noe rent standardhjem. Hvorfor er ikke bildene bare Files? Volum og lagringsøkonomi. Hvorfor en External ID? Et annet system trenger en stabil ID på tvers av grensen. Hvorfor eier integrasjonsbrukeren arbeidsordrene? Eierskap styrer ikke tilgang her, og det holder revisjonssporet ærlig. Hvorfor er mottakeren fortsatt åpen? Vi har ikke svart på nok spørsmål ennå. Linjene er resultatet; beslutningene skapte dem.

Så her er vanen jeg vil at du skal ta med deg ut av kapittel 3. Pek på hva som helst i en fysisk modell og spør hvorfor? Hvorfor dette objektet, denne typen, denne relasjonen, denne eieren, dette stedet, denne regelen? Du skal kunne spore svaret tilbake: fra konfigurasjonen, til den fysiske modellen, til den logiske modellen, til forretningskravet. Klarer du ikke det, har noen designet fra Setup.

Og du har sikkert lagt merke til tallene vi ikke har regnet helt gjennom: leveringer per partner, linjer, bilder, oppbevaring, arkivering. Bra. Spør etter antall nuller før du låser et design: en modell som fungerer nydelig med femti tusen poster, kan oppføre seg helt annerledes med fem hundre millioner. Det er del 2.

Utover eksamen: hva KI endrer. Gi en KI briefen for Steve Trucking, så lager den et skjema på sekunder: konto, arbeidsordre, egendefinerte objekter, felt, til og med metadata for deploy. Det er en fantastisk akselerator, og det er ikke gjennomgangen. Arkitektens jobb flytter seg til å sjekke koblingene og konsekvensene deres: passform, lisenser, eierskap, livssyklus, skala, identifikatorer, sikkerhet og hva som blir utenfor plattformen. KI er rakettboosteren; den forteller deg ikke om du peker i riktig retning.

Hva en arkitekt bestemmer her

• Hvordan hvert forretningsbegrep kobles til Salesforce: et standardobjekt, et egendefinert objekt eller noe utenfor core.
• Hvilke identifikatorer, felt og relasjoner som implementerer forretningsmeningen uten i det stille å endre den.
• Hvilken plattformatferd og hvilke lisenser som følger med en standardmodell du tar i bruk.
• Hvilke beslutninger om eierskap, livssyklus, konsistens, lagring og skala som må tas før designet er komplett.
• Hvilke spørsmål som eksplisitt holdes åpne, i stedet for å skjules bak et tilfeldig implementeringsvalg.

I starten av dette kapitlet spurte vi hvordan modellen skulle leve i Salesforce. Det er dataarkitektur i Salesforce: ikke å lage objekter, ikke å pugge Setup, ikke å tegne penere bokser, men bevisst å tilpasse forretningsmodellen til plattformens form. Hver struktur er en forpliktelse. Lag dem du kan forklare.

Les mer

• 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, kontrollert 2026-10-02).
• Briefen for Steve Trucking.