Relasjoner har konsekvenser

🌐 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 7 av 10 i kapitlet Dataarkitektur i Salesforce, kapittel 3 i kurset Data Architect. Hver modul står på egne ben. Forrige: Felt er også arkitektur · Neste: Eierskap og livssyklus

Spørsmålet denne modulen besvarer: Hva velger jeg egentlig når jeg kobler sammen to Salesforce-objekter?

Det er lett å tegne en relasjon. I kapittel 2 tegnet vi linjer og ga dem navn: en detaljhandelspartner sender mange manifester, en levering har mange linjer, team og lastebiler møtes i en teamtildeling (Crew Assignment). Vi snakket om kardinalitet, valgfrihet og historikk. Nå implementerer vi de linjene i Salesforce, og en linje på et diagram begynner å bære mye mer vekt.

Når jeg velger en relasjonstype i Salesforce, sier jeg ikke bare at disse to postene henger sammen. Jeg kan også bestemme hvem som eier barnet, om det kan finnes uten forelderen, hvem som kan se det, hva som skjer når forelderen slettes, om det kan flyttes til en annen forelder, om jeg kan summere det opp på forelderen, og hva som skjer når det finnes hundretusener av barn. En relasjon er ikke bare en linje. Den bærer oppførsel.

Begynn med forretningsrelasjonen

Før lookup eller master-detail: gå tilbake til forretningen. Ta en levering (Delivery) og leveringslinjene (Delivery Items), kjøleskapet, installasjonen, bortkjøringen av det gamle. Kan en linje finnes uten leveringen sin? Nei. Slettes leveringen, skal linjene forsvinne også? Ja. Trenger linjene sin egen eier eller sin egen sikkerhet? Egentlig ikke. Skal noen flytte en linje fra én levering til en annen? Forhåpentligvis ikke ved et uhell.

Ta så en levering og ruten (Route) den ligger på. Leveringen finnes før den blir rutet, den kan flyttes til en annen rute når planen endres, og å slette en rute skal aldri slette leveringene på den. To én-til-mange-linjer som ser like ut på et diagram, med helt forskjellig oppførsel. Legg merke til at vi fortsatt ikke har sagt «lookup» eller «master-detail». Beskriv oppførselen først. Konfigurasjonen implementerer den.

Relasjonstypene

Åpne skjermen New Field, og Salesforce tilbyr deg en håndfull relasjonstyper (Object Relationships Overview (opens in a new tab)):

• Lookup: kobler to objekter. Selve brød og smør i Salesforce-relasjoner.
• Master-detail: en forelder-barn-binding der forelderen styrer barnet.
• Mange-til-mange: ikke en egen felttype, men et mønster: et koblingsobjekt i Salesforce (Salesforce Junction Object), et egendefinert objekt med to master-detail-relasjoner.
• Selvrelasjon: en lookup-relasjon fra et objekt til seg selv.
• Hierarkisk (hierarchical): en spesiell lookup-relasjon som bare finnes på User-objektet, for eksempel en brukers leder.
• Ekstern lookup (external lookup) og indirekte lookup (indirect lookup): relasjonene til og fra eksterne objekter, __x-objektene fra modul 4. En ekstern lookup peker på et overordnet eksternt objekt; en indirekte lookup peker fra et eksternt objekt til et standardobjekt eller egendefinert objekt, matchet på en unik External ID.

Mesteparten av designtiden din går til de tre første. La oss ta dem én om gangen.

Lookup: disse postene henger sammen

En lookup-relasjon sier: denne posten er knyttet til den posten. Barnet beholder sin egen ID, sin egen eier og sitt eget liv. En levering peker på ruten sin. Blir ruten avlyst, forsvinner ikke leveringene; de går tilbake for å bli rutet på nytt.

Det er morsomt: lookup-feltet sitter på barnet, men forelderen får også noe, en relatert liste over barna sine. Så når du lager en, gi navn til begge ender. Related List Label er det folk ser på forelderen, og Child Relationship Name er det utviklere og integrasjoner bruker for å gå fra forelder til barn. Ikke godta standardverdiene.

En lookup-relasjon kan være obligatorisk eller valgfri. Når den er valgfri, bestemmer du hva som skjer hvis posten den peker på, slettes, og det finnes tre valg (Considerations for Object Relationships (opens in a new tab)):

• Clear the value of this field (tøm verdien i feltet), standardvalget. Barnet blir stående, med en tom lookup.
• Don’t allow deletion (ikke tillat sletting) av posten det slås opp mot. Prøv å slette ruten, og Salesforce sier nei: den er en del av en relasjon.
• Delete this record also (slett også denne posten), en kaskadesletting, som ved master-detail. Den tilbys bare for en egendefinert lookup på et egendefinert objekt, den er deaktivert som standard, og Salesforce må slå den på for orgen din, fordi en kaskadesletting går forbi sikkerhet og deling: brukere kan slette poster de ikke engang kunne se.

Det er en livssyklusbeslutning som gjemmer seg i en Setup-skjerm.

Oppslagsfiltre (lookup filters) snevrer inn hva en bruker kan velge. Si at Delivery har en Installer-lookup til Contact, og at installatører er én posttype av kontakter blant mange. Et oppslagsfilter viser bare installatører, og det kan filtrere på den gjeldende posten, på posten det slås opp mot, og på brukeren: profilen, rollen eller tillatelsene deres (Lookup Filters (opens in a new tab)). Det er en billig måte å holde en lookup-relasjon ærlig på.

Master-detail: dette barnet tilhører den forelderen

Master-detail kommer med en mye sterkere påstand. På kurs kaller jeg det en svært tett binding. Du kan ikke ha en detalj uten masteren sin; masterfeltet er obligatorisk. Detaljen mister sitt eget Owner-felt og arver eieren til forelderen. Det finnes ingen egen delingstabell for detaljen, så du kan ikke dele et barn for seg; det arver forelderens deling. Derfor kan et detaljobjekt ikke ha delingsregler, manuell deling eller køer: alle trenger et Owner-felt (Object Relationships Overview (opens in a new tab)). I Setup står delingsinnstillingen som Controlled by Parent (styrt av forelderen). Og på selve master-detail-feltet velger du en Sharing Setting: om en bruker trenger Read Only- eller Read/Write-tilgang til masteren for å opprette, redigere eller slette detaljene. Sletter du masteren, slettes detaljene. Og masteren får sammendragsfelt (roll-up summary).

Så hvis Delivery Item er en detalj av Delivery, sier jeg: denne linjen tilhører denne leveringen hele livet. Det er spørsmålet jeg vil ha besvart før noen velger Master-Detail Relationship i Setup.

Slettespørsmålet

Her er favorittmåten min å finne ut om vi har tenkt det gjennom på: hva skal skje med barna hvis noen sletter forelderen? Alle blir ukomfortable. Bra. Nå driver vi med arkitektur.

En detaljhandelspartner har hundretusener av historiske leveringer. Noen sletter partneren. Skal leveringene forsvinne? Nesten helt sikkert ikke: reklamasjonene, faktureringen og historikken avhenger alle av dem. Kanskje skal det slett ikke være lov å slette en partner, og partneren skal heller deaktiveres. Med master-detail går slettingen av masteren videre i kaskade til detaljene og deres detaljer; gjenopprettes masteren, kommer de tilbake (Considerations for Object Relationships (opens in a new tab)). Så når noen sier «master-detail gir oss sammendragsfelt», er svaret mitt: flott. Hva annet gikk du nettopp med på?

Eierskapet følger med på lasset

Med en lookup-relasjon kan barnet ha sin egen eier. Med master-detail kan det ikke det; tilgangen følger masteren. Det er helt riktig hvis detaljen virkelig er en del av forelderen. Men trenger barnet sin egen eier, sin egen deling eller sin egen livssyklus, forteller modellen deg at master-detail er feil valg. Neste modul går dypere inn i eierskap, og kurset Sharing and Visibility går enda lenger. Inntil videre: relasjonsdesign og sikkerhetsdesign er ikke separate samtaler. Datamodellen former sikkerhetsmodellen før noen skriver en delingsregel.

Obligatorisk forelder, eller valgfri?

Kan barnet finnes før vi kjenner forelderen? Det betyr mer enn det høres ut som. Kommer leveringene på manifestet kvelden før og rutene bygges etterpå, ville en obligatorisk Route på Delivery bety at rutingen må skje før posten i det hele tatt kan opprettes. Den fysiske relasjonen må støtte den ekte livssyklusen. Så jeg designer ikke relasjoner ut fra et statisk diagram alene. Jeg vil vite: hvordan blir de født, kan de finnes alene, kan de flytte, og hvordan dør de?

Kan barnet bytte forelder?

Som standard kan ikke et master-detail-barn flyttes til en annen forelder. Du kan tillate det ved å velge Allow reparenting på relasjonen (Considerations for Object Relationships (opens in a new tab)). Instinktet mitt er konservativt: sier forretningen at barnet tilhører én forelder hele livet, gjør jeg det ikke lett å flytte det. En linje som flyttes fra én levering til en annen, bør være en bevisst forretningshendelse, ikke en feltendring. Igjen: innstillingen er ikke arkitekturen. Livssyklusregelen er det, og innstillingen implementerer den.

To ting til som tar team senere. Du kan ikke lage en master-detail-relasjon på et objekt som allerede har data; du lager en lookup-relasjon, fyller den ut på hver post og konverterer den så. Og du kan bare konvertere tilbake til lookup hvis det ikke finnes sammendragsfelt på masteren. Følg også med på hva konverteringen gjør med sikkerheten: å gjøre en lookup om til master-detail setter barnets deling til Controlled by Parent, og å gjøre en master-detail om til lookup igjen setter barnets organisasjonsomfattende standard (organization-wide default) til Public Read/Write (Considerations for Object Relationships (opens in a new tab)). Poster som var private i går, er åpne i dag, helt til noen legger merke til det. Velg tidlig.

Sammendragsfelt er nyttige, men de er ikke gratis

Jeg liker sammendragsfelt. Tell linjene på en levering, summer linjebeløpene på en faktura, finn den seneste datoen: innebygd, uten kode. Master-detail-feltet sitter på barnet, men sammendragsfeltet sitter på forelderen. De kommer likevel med liten skrift (Roll-Up Summary Field (opens in a new tab)):

• Å beregne sammendragsverdier etter visse endringer (et nytt sammendragsfelt, en endret formel det avhenger av, en tvungen omberegning) kan ta opptil 30 minutter, avhengig av hvor mange poster som berøres. Jeg har sett folk lure på hvorfor tallet på forelderen ikke har endret seg ennå.
• De kan ikke summere alt. Et automatisk nummer (auto number) kan ikke være feltet du aggregerer. Og et sammendragsfelt kan bare summere et formelfelt hvis formelen ikke strekker seg over til et annet objekt og ikke bruker en funksjon som endrer seg av seg selv, som NOW() eller TODAY(). En «dager forsinket»-formel bygd på TODAY() endrer seg hver natt uten at noen lagrer en post, så det finnes ingenting sammendragsfeltet kan beregne på nytt ut fra. Et slikt tall trenger en planlagt flow, eller en rapport.
• Filteret har også grenser: ingen lange tekstområder, flervalgsplukklister, Description, systemfelt som Last Activity, formler på tvers av objekter eller lookup-felt.
• Sammendragsfelt finnes ikke på redigeringssider, så en valideringsregel kan bruke et, men kan ikke vise feilmeldingen sin der.

Og ikke snu beslutningen på hodet. Ikke si: «Vi trenger et sammendragsfelt, så dette må være master-detail.» Si: «Dette barnet tilhører virkelig denne forelderen, eierskapet og livssyklusen passer, og en av fordelene er innebygde sammendragsfelt.» Passer ikke semantikken, løs beregningen på en annen måte. Ikke forvreng datamodellen for å få en funksjon.

Så hva er den andre måten? Du bygger sammendraget selv: et felt på forelderen som holder den beregnede verdien, og automatisering som holder den oppdatert. Si at Retail Partner er en lookup fra Delivery, slik den bør være, og at forretningen vil ha Open Deliveries (åpne leveringer) på partneren. Legg til et tallfelt, Open Deliveries, på partneren. Så beregner en postutløst flow (record-triggered flow), eller en Apex-trigger når volumet eller logikken krever kode, det på nytt hver gang en levering endres. Det fungerer over en lookup-relasjon, det kan filtrere på hva som helst, og det kan bruke datoer og formler et innebygd sammendragsfelt ikke kan.

Men nå er det ditt ansvar å få det riktig, og det er der disse går galt. Automatiseringen må slå til ved hver endring som betyr noe: et nytt barn, et redigert barn, et slettet barn, et gjenopprettet barn og et barn som flyttes til en annen forelder, noe som betyr å beregne både den gamle og den nye forelderen på nytt. Den må tåle en datainnlasting på 200 poster om gangen uten å treffe grensene. Tell opp på nytt i stedet for å legge til og trekke fra, så én tapt hendelse ikke gjør tallet feil for alltid. Planlegg en måte å beregne alt på nytt, for den første innlastingen og den dagen tallet glir ut. Og husk at hver lagring av et barn nå oppdaterer forelderen, så en forelder med tusenvis av barn tar med seg låsingen vi skal se om et øyeblikk. Et innebygd sammendragsfelt gjør alt det for deg; et egendefinert er et lite stykke programvare du eier.

Tre nivåer dypt: master-detail i lag

Plattformen har en form, og master-detail har to dimensjoner av den. Den første er dybde.

Du kan stable master-detail-relasjoner tre egendefinerte detaljnivåer dypt, og der er bunnen (Considerations for Object Relationships (opens in a new tab)). På kurs tegner jeg det som en konto med en ordre (én), ordren med linjene sine (to) og linjene med detaljene sine (tre), og så prøver jeg å legge til en fjerde, og Salesforce lar meg ikke. Hos Steve Trucking kan det se slik ut: en Delivery (levering) er masteren; Delivery Items (leveringslinjer) er det første nivået; en linjes Install Tasks (installasjonsoppgaver) er det andre; og hver oppgaves Task Steps (oppgavesteg) er det tredje. Et fjerde nivå, for eksempel en Step Note (stegnotat), må være en lookup-relasjon.

Click to enlarge

Noen regler følger med stabelen:

• Standardobjekter kan ikke være på detaljsiden av et egendefinert objekt. Et egendefinert objekt kan være en detalj av Account; Account kan ikke være en detalj av ditt.
• Et objekt kan bare forekomme én gang i en stabel med flere nivåer. Salesforce vil ikke at du skal gå i ring tilbake til deg selv: en underdetalj kan ikke samtidig være master for sin egen master.
• Masteren kan ikke summere det nederste nivået direkte. Vil Delivery ha antall Task Steps, summerer Install Task stegene sine, Delivery Item summerer de sammendragene, og Delivery summerer linjene: ett nivå om gangen.
• Eierskap og deling kommer ovenfra. Hvert nivå arver eieren og tilgangen fra masteren.
• Sletter du masteren, slettes alt under den, og gjenoppretter du den, kommer alt tilbake.

Tre nivåer er som regel mer enn nok. Vil designet ditt stadig ha et fjerde, spør om hvert nivå virkelig tilhører nivået over hele livet. Og husk at du får velge hvilket ledd som bryter kjeden. Det fjerde nivået trenger ikke være lookup-relasjonen: kanskje tilhører ikke en Install Task egentlig leveringslinjen sin, den planlegges og tildeles for seg, så det leddet blir en lookup-relasjon, og nå starter Install Task en ny kjede med Task Step og Step Note under seg. Velg leddet der barnet virkelig har sitt eget liv, og gjør det til lookup-relasjonen.

Click to enlarge

Nå har Install Task sin egen eier og sin egen deling, en levering kan slettes uten å ta installasjonsoppgavene med seg, og Install Task kan ha to nivåer til under seg. Det er byttet: kjeden er kortere, og installasjonsoppgavens liv er dens eget.

To foreldre bredt: koblingsobjektet i Salesforce

Først et ord om ord, fordi «junction object» (koblingsobjekt) betyr to ting, og jeg underviser i begge.

I kapittel 2 fant vi det logiske koblingsobjektet: koblingen mellom to nøkkelidéer som blir en ting i seg selv, med egne attributter. En hund kan mange triks, et triks kan mange hunder, og Hundetriks sitter mellom dem og holder ferdighetsnivået og datoen. Det er et logisk koblingsobjekt, i den logiske modellen, lenge før noen bestemmer seg for lookup eller master-detail.

Salesforce bruker begrepet snevrere. Når Salesforce sier junction object, mener den et egendefinert objekt med to master-detail-relasjoner (Create a Many-to-Many Object Relationship (opens in a new tab)). Jeg kaller det et koblingsobjekt i Salesforce (Salesforce Junction Object). Hvert koblingsobjekt i Salesforce er et logisk koblingsobjekt, men ikke hvert logiske koblingsobjekt blir et koblingsobjekt i Salesforce: bygg et med én master-detail og én lookup, eller to lookup-relasjoner, så er det fortsatt et logisk koblingsobjekt, bare ikke av Salesforce-typen. (Salesforce er ikke helt konsekvent selv: dens egen objektreferanse kaller noen standardobjekter bygd på lookup-relasjoner for «junction objects». På eksamen: gå ut fra den snevre definisjonen.)

Eksamenskunnskap. Et koblingsobjekt i Salesforce (Salesforce Junction Object) er et egendefinert objekt med to master-detail-relasjoner, og det er det Salesforce mener når den sier «junction object». Det logiske koblingsobjektet er den bredere modelleringsidéen: ethvert objekt som kobler to andre i en mange-til-mange-relasjon og bærer egne attributter, uansett hvordan det er bygd.

Den andre dimensjonen er bredde. Kan et barn ha to master-detail-foreldre? Ja. Tre? Nei. Hvert egendefinert objekt kan ha opptil to master-detail-relasjoner (Considerations for Object Relationships (opens in a new tab)). To master-detail-foreldre er måten du bygger et koblingsobjekt i Salesforce på for en mange-til-mange-relasjon. Team (Crew) og lastebil (Truck) møtes i en teamtildeling (Crew Assignment), og som vi fant i kapittel 2, er det ikke rørleggerarbeid: den har en dato, en rute, kanskje en status. Koblingen er der relasjonen blir et forretningsbegrep. Salesforces tips for å bygge et: gi det et navn som sier hva det er, gjør postnavnet til et Auto Number, og gi hver masters relaterte liste navnet til den andre masteren, så Crew-siden viser «Trucks» og Truck-siden viser «Crews» (Create a Many-to-Many Object Relationship (opens in a new tab)).

Her er finessen. Én av de to foreldrene er den primære, og det er den hvis master-detail-felt du laget først. Det finnes ingen visuell indikasjon på hvilken det er, så det er et klassisk eksamensspørsmål, og en klassisk overraskelse.

Hva bestemmer den primære? Tre ting (Create a Many-to-Many Object Relationship (opens in a new tab)):

• Utseende. Sidene til koblingsobjektet bruker fargen og ikonet til den primære masteren.
• Eier. Koblingspostene arver eieren til den primære masterposten. Du ser det aldri, fordi en detalj ikke har noe Owner-felt; det betyr bare noe hvis du senere fjerner begge master-detail-relasjonene.
• Division, hvis orgen din bruker divisjoner, på samme måte.

Og den andre er den sekundære. Hva betyr det?

• Den står i kø for å bli primær. Slett det primære master-detail-feltet eller konverter det til en lookup-relasjon, og den sekundære blir den primære.
• Den setter omfanget for rapportene. Salesforce gir deg to rapporttyper: «Primary master with junction object and secondary master» og «Secondary master with junction object and primary master». Masteren som står først, avgjør hvilke poster rapporten kan vise.
• Den teller like mye for tilgang. Slik sier jeg det: eierskap fra den primære, tilgang fra begge, og den strengeste vinner. Et koblingsobjekt har, som enhver detalj, ingen egen delingstabell. Salesforce sjekker brukerens tilgang til begge masterpostene, gjennom Sharing Setting på hvert master-detail-felt. Er begge satt til Read/Write, trenger brukeren Read/Write på teamet og på lastebilen for å redigere teamtildelingen (Considerations for Object Relationships (opens in a new tab)).
• Den sletter like mye. Slett en av masterne, teamet eller lastebilen, og koblingspostene går i papirkurven (Recycle Bin). Slett begge, og de er borte for godt.

Click to enlarge

Noen regler til: begge masterne kan ha sammendragsfelt fra koblingsobjektet, og koblingsobjektets formler og valideringsregler kan nå felt på begge. Men et koblingsobjekt kan ikke være master for noe annet, så det kan ikke sitte midt i en stabel, og de to masterne kan ikke være det samme objektet; en mange-til-mange-relasjon fra et objekt til seg selv trenger et annet design. Og har en forelder mer enn 200 koblingsposter og koblingsobjektet summerer opp til den andre forelderen, lar ikke Salesforce deg slette den forelderen før du har fjernet nok av dem.

Så: hvilken forelder skal være primær? Lag den som eier meningen, først. For en teamtildeling er det teamet som gjør jobben, så jeg ville laget Crew først. Og skriv det så ned, for ingenting på skjermen kommer til å fortelle det til neste person.

Når det er sagt, ender jeg ikke opp med mange koblingsobjekter i Salesforce. Vanligvis har et objekt én master-detail-forelder, og det er samme type data: kundedata under kundedata, transaksjonsdata under transaksjonsdata (husk typene data fra kapittel 2: kunde, transaksjon, referanse). Når den andre forelderen er en annen type, som regel et referanseobjekt, er den relasjonen en lookup. En leveringslinje tilhører leveringen sin: master-detail, begge transaksjonsdata. Den peker på produktet den frakter med en lookup-relasjon, fordi et produkt er referansedata med et eget liv, og ingen vil at sletting av et produkt skal ta med seg år med leveringshistorikk. Leveringslinjen er fortsatt et logisk koblingsobjekt mellom en levering og produktene på den; den er bare ikke et koblingsobjekt i Salesforce.

Selvrelasjoner: når linjen kommer tilbake

Et objekt kan relateres til seg selv: en overordnet konto, en leder, et distribusjonssenter som rapporterer til et regionalt knutepunkt. Salesforce har bygd inn to du vil møte i nesten hver org: Account til Account, Parent Account-feltet som bygger kontohierarkiet, og Case til Case, Parent Case fra modul 2 som grupperer relaterte saker. En selvrelasjon må være en lookup-relasjon, og en post kan ikke peke på seg selv, selv om to poster kan peke på hverandre (Considerations for Object Relationships (opens in a new tab)). På User-objektet er det en egen spesialtype, den hierarkiske relasjonen, brukt til ting som en brukers leder. Mekanikken er enkel; navngivningen betyr noe. En lookup-relasjon fra Distribution Center til Distribution Center kalt Distribution_Center__c hjelper ingen. Overordnet? Reserve? Overløp? Gi relasjonen navn etter rollen, ikke etter objektet den peker på.

Click to enlarge

Hierarkisk: User-objektets egen relasjon

Denne er liten, og den er akkurat den typen lite kjente, unike faktum jeg ville forventet at en eksamen trekker på. Hierarkisk (hierarchical) er en spesiell lookup-relasjon som finnes bare på User-objektet. Den kobler én bruker til en annen bruker, og Salesforce lar ikke kjeden gå i ring: en bruker kan ikke peke på seg selv, direkte eller indirekte (Object Relationships Overview (opens in a new tab)). Er Marias leder Dev, kan ikke Devs leder være Maria, eller noen som rapporterer oppover til Maria.

Det er forskjellen fra selvrelasjonene over. På Account eller et egendefinert objekt kan to poster peke på hverandre. På User må hierarkiet forbli et hierarki. Og det er den eneste måten å relatere User til User på: en vanlig lookup-relasjon fra User til seg selv tilbys ikke.

Du har allerede en. Standardfeltet Manager på User er en hierarkisk relasjon, og godkjenninger kan bruke det: send denne forespørselen til innsenderens leder. Du kan også lage dine egne, for eksempel en Escalation Contact eller en Backup Approver, og en godkjenning kan rutes langs den på samme måte (ApprovalProcess, Metadata API (opens in a new tab)). Ikke bland den sammen med rollehierarkiet, som styrer tilgang til poster. Et hierarkisk felt er bare en relasjon mellom brukere; det deler ikke en eneste post.

Eksamenskunnskap. Den hierarkiske relasjonen finnes bare på User-objektet, som standardfeltet Manager, og en bruker kan ikke peke på seg selv, direkte eller indirekte. Den er ikke rollehierarkiet.

Relasjoner har også grenser

Hvert objekt kan ha høyst to master-detail-relasjoner. Lookup- og master-detail-felt teller sammen som relasjonsfelt: 40 per objekt som standard, høyst 50 på forespørsel. Sammendragsfelt: 25 per objekt som standard, høyst 40 (Increase the Maximum Relationships Allowed per Object (opens in a new tab); Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab)). Salesforce legger til at å heve en av grensene kan påvirke ytelsen.

Du trenger ikke designe etter de tallene; du må legge merke til når du nærmer deg dem. Et objekt med relasjon etter relasjon hengende på seg forteller deg noe. Kanskje er det virkelig så sentralt. Eller kanskje er modellen feil. (Og regelen om klaring fra kapittel 18 gjelder: hold deg godt under en grense, målt mot år tre.)

Spørsmålet om 10 000 barn

Så er det forelderen med for mange barn. Salesforces egen veiledning er ikke å overstige omtrent 10 000 barneposter for én master-detail-forelder (Considerations for Object Relationships (opens in a new tab)), og veiledningen deres for posttilgang i stor skala sier det samme om forelder-barn-relasjoner generelt (Parent-Child Data Skew (opens in a new tab)). Post nummer 10 001 knekker ikke orgen. Men forbi det punktet kan lagring av et barn låse forelderen, og delingsendringer på forelderen forplanter seg gjennom hvert barn.

Så når jeg ser én forelder, enorme mengder barn, spør jeg: hvorfor ligger de alle under samme forelder, hvem eier dem, hvordan spørres de, og hvilken automatisering rører forelderen? Hver levering under én enkelt «Steve Trucking»-konto ville passert 10 000 på noen få dager. En uskyldig én-til-mange-relasjon blir et skew-problem (data skew). Neste modul gir en forsmak på skew, og del 2 går i dybden.

Ikke design linjen etter funksjon

Dette er vanen jeg vil at du skal ta med fra denne modulen. Ikke begynn med «jeg trenger et sammendragsfelt», «jeg trenger at den er obligatorisk», «jeg vil ha arvet deling». Det er implementeringshint. Begynn med forretningen: har barnet sitt eget liv, hvem eier det, kan det finnes alene, kan det flytte, hva skjer når forelderen forsvinner, bærer relasjonen data, og hvor stor kan hver side bli? Velg så relasjonen som implementerer svarene.

Click to enlarge

Utover eksamen: hva KI endrer. KI kan foreslå relasjoner på sekunder. Den kan ikke fortelle deg om forretningen noen gang kommer til å slette forelderen. Raskere diagramtegning gjør ikke en feil relasjon billigere å reversere når millioner av poster og dusinvis av automatiseringer avhenger av den.

Hva en arkitekt bestemmer her

• Om barnet har sin egen livssyklus eller virkelig tilhører forelderen, og om eierskap og tilgang skal være dets egne eller arvet.
• Om barnet kan finnes uten en forelder, flytte mellom foreldre eller overleve at forelderen slettes.
• Hva hver lookup-relasjon gjør når forelderen slettes: tømme, blokkere eller kaskadeslette.
• Om en mange-til-mange-relasjon er rørleggerarbeid eller et forretningsbegrep, om det logiske koblingsobjektet blir et koblingsobjekt i Salesforce, hvilken forelder som er primær, og hva begge foreldrene betyr for tilgangen.
• Om modellen passer plattformens form: tre egendefinerte detaljnivåer dypt, to master-detail-foreldre bredt, grensene for relasjoner og sammendragsfelt.
• Om forventet antall og fordeling av barn skaper en skew-risiko som bør endre designet.

En relasjon er et sett løfter om hvordan to databiter oppfører seg sammen. Gi dem med vilje.

Les mer

• Salesforce Help, Considerations for Object Relationships (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Help, Object Relationships Overview (opens in a new tab) og Create a Many-to-Many Object Relationship (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Help, Roll-Up Summary Field (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Help, Lookup Filters (opens in a new tab), på engelsk, kontrollert 2026-10-13.
• Salesforce Help, Increase the Maximum Relationships Allowed per Object (opens in a new tab) og Increase the Maximum Limit of Roll-Up Summary Fields (opens in a new tab), på engelsk, kontrollert 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab), på engelsk, kontrollert 2026-10-02.