Relationer har konsekvenser

🌐 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 7 af 10 i kapitlet Dataarkitektur i Salesforce, kapitel 3 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Felter er også arkitektur · Næste: Ejerskab og livscyklus

Spørgsmålet, dette modul besvarer: Hvad vælger jeg egentlig, når jeg forbinder to objekter i Salesforce?

Det er nemt at tegne en relation. I kapitel 2 tegnede vi linjer og gav dem navne: En detailpartner sender mange manifester, en levering indeholder mange varer, teams og lastbiler mødes i en teamtildeling (Crew Assignment). Vi talte om kardinalitet, valgfrihed og historik. Nu implementerer vi de linjer i Salesforce, og en linje i et diagram begynder at bære meget mere vægt.

Når jeg vælger en relationstype i Salesforce, siger jeg ikke bare, at disse to poster hænger sammen. Jeg beslutter måske også, hvem der ejer barnet, om det kan eksistere uden forælderen, hvem der kan se det, hvad der sker, når forælderen slettes, om det kan flytte til en anden forælder, om jeg kan opsummere det på forælderen, og hvad der sker, når der er hundredtusindvis af børn. En relation er ikke bare en linje. Den bærer adfærd.

Start med forretningsrelationen

Før lookup eller master-detail, så gå tilbage til forretningen. Tag en levering (Delivery) og dens leveringslinjer (Delivery Items): køleskabet, installationen, bortskaffelsen. Kan en linje eksistere uden sin levering? Nej. Hvis leveringen slettes, skal dens linjer så også forsvinde? Ja. Har linjerne brug for deres egen ejer eller deres egen sikkerhed? Egentlig ikke. Skal nogen flytte en linje fra én levering til en anden? Forhåbentlig ikke ved et uheld.

Tag nu en levering og den rute (Route), den ligger på. Leveringen findes, før den bliver planlagt på en rute, den kan flyttes til en anden rute, når planen ændrer sig, og at slette en rute bør aldrig slette leveringerne på den. To én-til-mange-linjer, der ser ens ud i et diagram, med helt forskellig adfærd. Læg mærke til, at vi stadig ikke har sagt »lookup« eller »master-detail«. Beskriv adfærden først. Konfigurationen implementerer den.

Relationstyperne

Åbn skærmen New Field, og Salesforce tilbyder dig en håndfuld relationstyper (Object Relationships Overview (opens in a new tab)):

• Lookup: forbinder to objekter. Salesforce-relationernes daglige brød.
• Master-detail: en binding mellem forælder og barn, hvor forælderen styrer barnet.
• Mange-til-mange: ikke en selvstændig felttype, men et mønster: et forbindelsesobjekt i Salesforce (Salesforce Junction Object), et brugerdefineret objekt med to master-detail-relationer.
• Selvrelation: et lookup fra et objekt til sig selv.
• Hierarkisk: et særligt lookup, der kun findes på User-objektet, som en brugers leder.
• External lookup og indirect lookup: relationerne til og fra eksterne objekter, __x-objekterne fra modul 4. Et external lookup peger på et eksternt forælderobjekt; et indirect lookup peger fra et eksternt objekt til et standardobjekt eller brugerdefineret objekt, matchet på et unikt External ID.

Det meste af din designtid går til de første tre. Lad os tage dem én ad gangen.

Lookup: disse poster hænger sammen

Et lookup siger: Denne post er knyttet til den post. Barnet beholder sin egen selvstændighed, sin egen ejer og sit eget liv. En levering peger på sin rute. Hvis ruten aflyses, forsvinder leveringerne ikke; de går tilbage og bliver planlagt igen.

Det er pudsigt: Lookup-feltet sidder på barnet, men forælderen får også noget, en relateret liste over sine børn. Så når du opretter et, så navngiv begge ender. Related List Label er det, folk ser på forælderen, og Child Relationship Name er det, udviklere og integrationer bruger til at gå fra forælder til børn. Accepter ikke standardværdierne.

Et lookup kan være påkrævet eller valgfrit. Når det er valgfrit, beslutter du, hvad der sker, hvis den post, det peger på, slettes, og der er tre valg (Considerations for Object Relationships (opens in a new tab)):

• Clear the value of this field (ryd feltets værdi), standardvalget. Barnet bliver, med et tomt lookup.
• Don’t allow deletion (tillad ikke sletning) af lookup-posten. Prøv at slette ruten, og Salesforce siger nej: Den er en del af en relation.
• Delete this record also (slet også denne post), en kaskadesletning som ved master-detail. Den tilbydes kun for et brugerdefineret lookup på et brugerdefineret objekt, den er slået fra som standard, og Salesforce skal slå den til for din org, fordi en kaskadesletning går uden om sikkerhed og deling: Brugere kan slette poster, de ikke engang kunne se.

Det er en livscyklusbeslutning, der gemmer sig på en opsætningsskærm.

Lookup-filtre indsnævrer, hvad en bruger kan vælge. Lad os sige, at Delivery har et Installer-lookup til Contact, og at installatører er én posttype af kontakt blandt mange. Et lookup-filter viser kun installatører, og det kan filtrere på den aktuelle post, på den post, der slås op, og på brugeren: dennes profil, rolle eller tilladelser (Lookup Filters (opens in a new tab)). Det er en billig måde at holde et lookup ærligt på.

Master-detail: dette barn tilhører den forælder

Master-detail siger noget meget stærkere. I klassen kalder jeg det en meget tæt binding. Du kan ikke have en detalje uden dens master; masterfeltet er påkrævet. Detaljen mister sit eget Owner-felt og arver forælderens ejer. Der er ingen separat delingstabel for detaljen, så du kan ikke dele et barn for sig selv; det arver forælderens deling. Derfor kan et detaljeobjekt ikke have delingsregler, manuel deling eller køer: De kræver alle et Owner-felt (Object Relationships Overview (opens in a new tab)). I Setup står delingsindstillingen som Controlled by Parent (styret af forælderen). Og på selve master-detail-feltet vælger du en Sharing Setting: om en bruger skal have Read Only- eller Read/Write-adgang til masteren for at oprette, redigere eller slette dens detaljer. At slette masteren sletter dens detaljer. Og masteren får oversigtsfelter (roll-up summary).

Så hvis leveringslinjen er en detalje af leveringen, siger jeg: Denne linje tilhører denne levering hele sit liv. Det er det spørgsmål, jeg vil have besvaret, før nogen vælger Master-Detail Relationship i Setup.

Spørgsmålet om sletning

Her er min yndlingsmåde at finde ud af, om vi har tænkt det igennem: Hvad skal der ske med børnene, hvis nogen sletter forælderen? Alle bliver utilpasse. Godt. Nu laver vi arkitektur.

En detailpartner har hundredtusindvis af historiske leveringer. Nogen sletter partneren. Skal leveringerne forsvinde? Næsten helt sikkert ikke: Reklamationerne, faktureringen og historikken afhænger alle af dem. Måske burde det slet ikke være tilladt at slette en partner, og partneren burde i stedet deaktiveres. Med master-detail kaskaderer sletning af masteren til detaljerne og deres detaljer; gendannes masteren, kommer de tilbage (Considerations for Object Relationships (opens in a new tab)). Så når nogen siger »master-detail giver os roll-ups«, er mit svar: Fint. Hvad har du ellers lige sagt ja til?

Ejerskabet kører med

Med et lookup kan barnet have sin egen ejer. Med master-detail kan det ikke; adgangen følger masteren. Det er helt rigtigt, hvis detaljen virkelig er en del af forælderen. Men hvis barnet har brug for sin egen ejer, sin egen deling eller sin egen livscyklus, fortæller modellen dig, at master-detail er det forkerte valg. Næste modul går dybere ind i ejerskab, og kurset Sharing and Visibility går endnu længere. Indtil videre: Relationsdesign og sikkerhedsdesign er ikke to separate samtaler. Datamodellen former sikkerhedsmodellen, før nogen skriver en delingsregel.

Påkrævet forælder eller valgfri?

Kan barnet eksistere, før vi kender dets forælder? Det betyder mere, end det lyder. Hvis leveringerne ankommer på manifestet aftenen før, og ruterne bygges bagefter, ville en påkrævet rute på leveringen betyde, at ruteplanlægningen skal ske, før posten overhovedet kan oprettes. Den fysiske relation skal understøtte den virkelige livscyklus. Så jeg designer ikke relationer ud fra et statisk diagram alene. Jeg vil vide: Hvordan bliver de født, kan de eksistere alene, kan de flytte, og hvordan dør de?

Kan barnet skifte forælder?

Som standard kan et master-detail-barn ikke flyttes til en anden forælder. Du kan tillade det ved at vælge Allow reparenting på relationen (Considerations for Object Relationships (opens in a new tab)). Mit instinkt er konservativt: Hvis forretningen siger, at barnet tilhører én forælder hele livet, gør jeg det ikke nemt at flytte det. At en linje flytter fra én levering til en anden, bør være en bevidst forretningshændelse, ikke en feltredigering. Igen: Indstillingen er ikke arkitekturen. Livscyklusreglen er, og indstillingen implementerer den.

To ting mere, der fanger teams senere. Du kan ikke oprette en master-detail-relation på et objekt, der allerede har data; du opretter et lookup, udfylder det på hver post og konverterer det så. Og du kan kun konvertere tilbage til et lookup, hvis der ikke er nogen oversigtsfelter på masteren. Hold også øje med, hvad konverteringen gør ved sikkerheden: At gøre et lookup til en master-detail sætter barnets deling til Controlled by Parent, og at gøre en master-detail tilbage til et lookup sætter barnets organisationsdækkende standard (organization-wide default) til Public Read/Write (Considerations for Object Relationships (opens in a new tab)). Poster, der var private i går, er åbne i dag, indtil nogen opdager det. Vælg tidligt.

Roll-ups er nyttige, men de er ikke gratis

Jeg kan godt lide roll-ups. Tæl linjerne på en levering, summér linjebeløbene på en faktura, find den seneste dato: indbygget, uden kode. Master-detail-feltet sidder på barnet, men roll-up-feltet sidder på forælderen. De kommer dog med småt (Roll-Up Summary Field (opens in a new tab)):

• Beregningen af roll-up-værdier efter visse ændringer (et nyt roll-up-felt, en ændret formel, det afhænger af, en tvungen genberegning) kan tage op til 30 minutter, afhængigt af hvor mange poster der berøres. Jeg har set folk undre sig over, hvorfor tallet på forælderen ikke har ændret sig endnu.
• De kan ikke opsummere alt. Et autonummer kan ikke være det felt, du aggregerer. Og et roll-up kan kun opsummere et formelfelt, hvis formlen ikke rækker over til et andet objekt og ikke bruger en funktion, der ændrer sig af sig selv, som NOW() eller TODAY(). En formel for »dage over forfald« bygget på TODAY() ændrer sig hver nat, uden at nogen gemmer en post, så der er intet for roll-up’et at genberegne ud fra. Den slags tal kræver et planlagt flow eller en rapport.
• Filteret har også grænser: ingen lange tekstområder, flervalgslister, Description, systemfelter som Last Activity, formler på tværs af objekter eller lookup-felter.
• Roll-ups vises ikke på redigeringssider, så en valideringsregel kan bruge et, men kan ikke vise sin fejl der.

Og vend ikke beslutningen på hovedet. Sig ikke: »Vi har brug for et roll-up, så det her må være master-detail.« Sig: »Dette barn tilhører virkelig denne forælder, ejerskabet og livscyklussen passer, og en af fordelene er indbyggede roll-ups.« Hvis betydningen ikke passer, så løs beregningen på en anden måde. Forvræng ikke datamodellen for at få en funktion.

Så hvad er den anden måde? Du bygger roll-up’et selv: et felt på forælderen, der rummer den beregnede værdi, og automatisering, der holder det opdateret. Lad os sige, at detailpartneren er et lookup fra leveringen, som den bør være, og at forretningen vil have Open Deliveries (åbne leveringer) på partneren. Tilføj et talfelt, Open Deliveries, til partneren. Så genberegner et record-triggered flow, eller en Apex-trigger, når volumen eller logikken kræver kode, det, hver gang en levering ændres. Det virker over et lookup, det kan filtrere på hvad som helst, og det kan bruge datoer og formler, som et indbygget roll-up ikke kan.

Men nu er det dit ansvar at få det rigtigt, og det er her, de går galt. Automatiseringen skal køre ved hver ændring, der betyder noget: et nyt barn, et redigeret barn, et slettet barn, et gendannet barn og et barn, der flyttes til en anden forælder, hvilket betyder, at både den gamle og den nye forælder skal genberegnes. Den skal kunne håndtere en dataindlæsning på 200 poster ad gangen uden at ramme grænser. Tæl forfra i stedet for at lægge til og trække fra, så én overset hændelse ikke efterlader tallet forkert for altid. Planlæg en måde at genberegne alt på, til den første indlæsning og den dag, det glider. Og husk, at hver gang et barn gemmes, opdateres forælderen nu, så en forælder med tusindvis af børn bringer den låsning tilbage, som vi ser om lidt. Et indbygget roll-up gør alt det for dig; et brugerdefineret er et lille stykke software, du ejer.

Tre niveauer dybt: master-details stablet

Platformen har en form, og master-detail har to dimensioner af den. Den første er dybde.

Du kan stable master-details tre brugerdefinerede detaljeniveauer dybt, og så er du i bund (Considerations for Object Relationships (opens in a new tab)). I klassen tegner jeg det som en konto med en ordre (ét), ordren med dens linjer (to) og linjerne med deres detaljer (tre), og så prøver jeg at tilføje et fjerde, og Salesforce vil ikke lade mig. Hos Steve Trucking kunne det se sådan ud: En levering (Delivery) er masteren; dens leveringslinjer (Delivery Items) er det første niveau; en linjes installationsopgaver (Install Tasks) er det andet; og hver opgaves opgavetrin (Task Steps) er det tredje. Et fjerde niveau, lad os sige en trinnote (Step Note), skal være et lookup.

Click to enlarge

Der følger et par regler med stablen:

• Standardobjekter kan ikke være på detaljesiden af et brugerdefineret objekt. Et brugerdefineret objekt kan være en detalje af Account; Account kan ikke være en detalje af dit.
• Et objekt kan kun optræde én gang i en stabel med flere niveauer. Salesforce vil ikke have, at du laver en løkke tilbage til dig selv: En underdetalje kan ikke også være master for sin egen master.
• Masteren kan ikke lave roll-up direkte fra det nederste niveau. Hvis leveringen vil have antallet af opgavetrin, laver installationsopgaven roll-up af sine trin, leveringslinjen laver roll-up af de roll-ups, og leveringen laver roll-up af linjerne: ét niveau ad gangen.
• Ejerskab og deling kommer fra toppen. Hvert niveau arver masterens ejer og adgang.
• At slette masteren sletter alt under den, og at gendanne den bringer alt tilbage.

Tre niveauer er som regel rigeligt. Hvis dit design bliver ved med at ville have et fjerde, så spørg, om hvert niveau virkelig tilhører det ovenover hele livet. Og husk, at du selv vælger, hvilket led der bryder kæden. Det fjerde niveau behøver ikke at være lookup’et: Måske tilhører en installationsopgave ikke rigtig sin leveringslinje, den planlægges og tildeles for sig selv, så det led bliver et lookup, og nu starter installationsopgaven en ny kæde med opgavetrin og trinnote under sig. Vælg det led, hvor barnet virkelig har sit eget liv, og gør det til lookup’et.

Click to enlarge

Nu har installationsopgaven sin egen ejer og sin egen deling, en levering kan slettes uden at tage sine installationsopgaver med sig, og installationsopgaven kan have to niveauer mere under sig. Det er byttehandlen: Kæden er kortere, og installationsopgavens liv er dens eget.

To forældre bredt: forbindelsesobjektet i Salesforce

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

I kapitel 2 fandt vi det logiske forbindelsesobjekt: forbindelsen mellem to centrale idéer, der bliver til en ting i sig selv, med sine egne attributter. En hund kan mange tricks, et trick kendes af mange hunde, og Hundetrick sidder imellem dem og rummer færdighedsniveauet og datoen. Det er et logisk forbindelsesobjekt, i den logiske model, længe før nogen beslutter lookup eller master-detail.

Salesforce bruger begrebet snævrere. Når Salesforce siger junction object, mener den et brugerdefineret objekt med to master-detail-relationer (Create a Many-to-Many Object Relationship (opens in a new tab)). Det kalder jeg et forbindelsesobjekt i Salesforce (Salesforce Junction Object). Hvert forbindelsesobjekt i Salesforce er et logisk forbindelsesobjekt, men ikke hvert logisk forbindelsesobjekt bliver et forbindelsesobjekt i Salesforce: Byg et med en master-detail og et lookup, eller to lookups, og det er stadig et logisk forbindelsesobjekt, bare ikke Salesforce-udgaven. (Salesforce er ikke selv helt konsekvent: Dens egen objektreference kalder nogle standardobjekter, der er bygget på lookups, for »junction objects«. Til eksamen skal du gå ud fra den snævre definition.)

Eksamensviden. Et forbindelsesobjekt i Salesforce (Salesforce Junction Object) er et brugerdefineret objekt med to master-detail-relationer, og det er det, Salesforce mener, når den siger »junction object«. Det logiske forbindelsesobjekt er den bredere modelleringsidé: ethvert objekt, der forbinder to andre i en mange-til-mange-relation og bærer sine egne attributter, uanset hvordan det er bygget.

Den anden dimension er bredde. Kan et barn have to master-detail-forældre? Ja. Tre? Nej. Hvert brugerdefineret objekt kan have op til to master-detail-relationer (Considerations for Object Relationships (opens in a new tab)). To master-detail-forældre er måden, du bygger et forbindelsesobjekt i Salesforce til en mange-til-mange-relation på. Team (Crew) og lastbil (Truck) mødes i en teamtildeling (Crew Assignment), og som vi fandt ud af i kapitel 2, er det ikke VVS: Den har en dato, en rute, måske en status. Forbindelsen er der, hvor relationen bliver et forretningsbegreb. Salesforces tips til at bygge et: Giv det et navn, der siger, hvad det er, gør dets postnavn til et autonummer, og omdøb hver masters relaterede liste til den anden master, så teamets side viser »Lastbiler«, og lastbilens side viser »Teams« (Create a Many-to-Many Object Relationship (opens in a new tab)).

Her er finessen. Den ene af de to forældre er den primære, og det er den, hvis master-detail-felt du oprettede først. Der er ingen visuel markering af, hvilken det er, så det er et klassisk eksamensspørgsmål og en klassisk overraskelse.

Hvad afgør den primære? Tre ting (Create a Many-to-Many Object Relationship (opens in a new tab)):

• Udseende. Forbindelsesobjektets sider bruger den primære masters farve og ikon.
• Ejer. Forbindelsesposterne arver ejeren af den primære masterpost. Du ser det aldrig, fordi en detalje ikke har noget Owner-felt; det betyder kun noget, hvis du senere fjerner begge master-detail-relationer.
• Division, hvis din org bruger divisioner, på samme måde.

Og den anden er den sekundære. Hvad betyder det?

• Den står i kø til at blive primær. Slet det primære master-detail-felt, eller konvertér det til et lookup, og den sekundære bliver den primære.
• Den sætter rammen for rapporterne. Salesforce giver dig to rapporttyper: »Primary master with junction object and secondary master« og »Secondary master with junction object and primary master«. Den master, der står først, afgør, hvilke poster rapporten kan vise.
• Den tæller lige så meget for adgangen. Sådan siger jeg det: ejerskab fra den primære, adgang fra begge, og den mest restriktive vinder. Et forbindelsesobjekt har ligesom enhver detalje ingen delingstabel for sig selv. Salesforce tjekker brugerens adgang til begge masterposter gennem Sharing Setting på hvert master-detail-felt. Hvis begge er sat til Read/Write, skal brugeren have Read/Write på teamet og på lastbilen for at redigere teamtildelingen (Considerations for Object Relationships (opens in a new tab)).
• Den sletter lige så meget. Slet en af masterne, teamet eller lastbilen, og dens forbindelsesposter ryger i papirkurven (Recycle Bin). Slet begge, og de er væk for altid.

Click to enlarge

Et par regler mere: Begge mastere kan have oversigtsfelter fra forbindelsesobjektet, og forbindelsesobjektets formler og valideringsregler kan nå felter på begge. Men et forbindelsesobjekt kan ikke være master for noget andet, så det kan ikke sidde midt i en stabel, og de to mastere kan ikke være det samme objekt; en mange-til-mange-relation fra et objekt til sig selv kræver et andet design. Og hvis en forælder har mere end 200 forbindelsesposter, og forbindelsesobjektet laver roll-up til den anden forælder, lader Salesforce dig ikke slette den forælder, før du har fjernet nok af dem.

Så: Hvilken forælder skal være primær? Opret den, der ejer betydningen, først. For en teamtildeling er det teamet, der udfører arbejdet, så jeg ville oprette Crew først. Og skriv det så ned, for intet på skærmen vil fortælle den næste person det.

Når det så er sagt, ender jeg ikke med mange forbindelsesobjekter i Salesforce. Typisk har et objekt én master-detail-forælder, og det er den samme slags data: kundedata under kundedata, transaktionsdata under transaktionsdata (husk kapitel 2’s typer af data: kunde-, transaktions- og referencedata). Når dets anden forælder er en anden slags, som regel et referenceobjekt, er den relation et lookup. En leveringslinje tilhører sin levering: master-detail, begge transaktionsdata. Den peger på det produkt, den indeholder, med et lookup, fordi et produkt er referencedata med sit eget liv, og ingen vil have, at sletning af et produkt tager mange års leveringshistorik med sig. Leveringslinjen er stadig et logisk forbindelsesobjekt mellem en levering og produkterne på den; den er bare ikke et forbindelsesobjekt i Salesforce.

Selvrelationer: når linjen kommer tilbage

Et objekt kan relatere til sig selv: en overordnet konto, en leder, et distributionscenter, der refererer til et regionalt knudepunkt. Salesforce har to indbygget, som du møder i næsten alle org’er: Account til Account, feltet Parent Account, der bygger kontohierarkiet, og Case til Case, Parent Case fra modul 2, der grupperer relaterede sager. En selvrelation skal være et lookup, og en post kan ikke pege på sig selv, men to poster kan godt pege på hinanden (Considerations for Object Relationships (opens in a new tab)). På User-objektet er det en særlig type for sig, den hierarkiske relation, der bruges til ting som en brugers leder. Mekanikken er nem; navngivningen betyder noget. Et lookup fra Distribution Center til Distribution Center ved navn Distribution_Center__c hjælper ingen. Overordnet? Backup? Overløb? Navngiv relationen efter rollen, ikke efter det objekt, den peger på.

Click to enlarge

Hierarkisk: User-objektets egen relation

Den her er lille, og den er præcis den slags lidet kendte, enestående faktum, jeg ville forvente, at en eksamen trækker på. Hierarkisk (hierarchical) er et særligt lookup, der kun findes på User-objektet. Det forbinder én bruger med en anden bruger, og Salesforce lader ikke kæden lave en løkke: En bruger kan ikke pege på sig selv, hverken direkte eller indirekte (Object Relationships Overview (opens in a new tab)). Hvis Marias leder er Dev, kan Devs leder ikke være Maria eller nogen, der refererer op til Maria.

Det er forskellen fra selvrelationerne ovenfor. På Account eller et brugerdefineret objekt kan to poster pege på hinanden. På User skal hierarkiet forblive et hierarki. Og det er den eneste måde at relatere User til User på: Et almindeligt lookup fra User til sig selv tilbydes ikke.

Du har allerede én. Standardfeltet Manager på User er en hierarkisk relation, og godkendelser kan bruge det: Send denne anmodning til indsenderens leder. Du kan også oprette dine egne, lad os sige en Escalation Contact eller en Backup Approver, og en godkendelse kan følge den på samme måde (ApprovalProcess, Metadata API (opens in a new tab)). Forveksl det ikke med rollehierarkiet, som styrer adgangen til poster. Et hierarkisk felt er bare en relation mellem brugere; det deler ikke en eneste post.

Eksamensviden. Den hierarkiske relation findes kun på User-objektet, som standardfeltet Manager, og en bruger kan ikke pege på sig selv, hverken direkte eller indirekte. Den er ikke rollehierarkiet.

Relationer har også grænser

Hvert objekt kan højst have to master-detail-relationer. Lookup- og master-detail-felter tæller tilsammen som relationsfelter: 40 pr. objekt som standard, højst 50 efter anmodning. Oversigtsfelter (roll-up summary): 25 pr. objekt som standard, højst 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 tilføjer, at det kan påvirke ydeevnen at hæve en af grænserne.

Du behøver ikke at designe efter de tal; du skal lægge mærke til, når du nærmer dig dem. Et objekt med relation efter relation hængende på sig fortæller dig noget. Måske er det virkelig så centralt. Eller måske er modellen forkert. (Og kapitel 18’s regel om luft til grænsen gælder: Hold dig et godt stykke under en grænse, målt i forhold til år tre.)

Spørgsmålet om de 10.000 børn

Og så er der forælderen med for mange børn. Salesforces egen vejledning er ikke at overstige cirka 10.000 underordnede poster for én master-detail-forælder (Considerations for Object Relationships (opens in a new tab)), og dens guide til adgang til poster i stor skala siger det samme for relationer mellem forælder og barn generelt (Parent-Child Data Skew (opens in a new tab)). Post nummer 10.001 ødelægger ikke org’en. Men forbi det punkt kan det at gemme et barn låse forælderen, og delingsændringer på forælderen forplanter sig gennem hvert eneste barn.

Så når jeg ser én forælder med enorme mængder børn, spørger jeg: Hvorfor er de alle under den samme forælder, hvem ejer dem, hvordan forespørges de, og hvilken automatisering rører forælderen? Hver levering under én enkelt »Steve Trucking«-konto ville passere 10.000 på få dage. En uskyldig én-til-mange-relation bliver et skew-problem. Næste modul giver en forsmag på data skew, og del 2 går i dybden.

Design ikke linjen efter funktionen

Det er den vane, jeg vil have fra dette modul. Start ikke fra »jeg har brug for et roll-up«, »det skal være påkrævet«, »jeg vil have nedarvet deling«. Det er implementeringsspor. Start fra forretningen: Har barnet sit eget liv, hvem ejer det, kan det eksistere alene, kan det flytte, hvad sker der, når forælderen forsvinder, bærer relationen data, og hvor stor kan hver side blive? Vælg så den relation, der implementerer svarene.

Click to enlarge

Ud over eksamen: hvad AI ændrer. AI kan foreslå relationer på få sekunder. Den kan ikke fortælle dig, om forretningen nogensinde vil slette forælderen. Hurtigere diagrammer gør ikke en forkert relation billigere at rulle tilbage, når millioner af poster og snesevis af automatiseringer afhænger af den.

Hvad en arkitekt beslutter her

• Om barnet har sin egen livscyklus eller virkelig tilhører forælderen, og om ejerskab og adgang skal være dets egne eller nedarvede.
• Om barnet kan eksistere uden en forælder, flytte mellem forældre eller overleve forælderens sletning.
• Hvad hvert lookup gør, når dets forælder slettes: rydder, blokerer eller kaskaderer.
• Om en mange-til-mange-relation er VVS eller et forretningsbegreb, om det logiske forbindelsesobjekt bliver et forbindelsesobjekt i Salesforce, hvilken forælder der er primær, og hvad begge forældre betyder for adgangen.
• Om modellen passer til platformens form: tre brugerdefinerede detaljeniveauer dybt, to master-detail-forældre bredt, grænserne for relationer og roll-ups.
• Om det forventede antal børn og deres fordeling skaber en skew-risiko, der bør ændre designet.

En relation er et sæt løfter om, hvordan to stykker data opfører sig sammen. Giv dem med vilje.

Læs mere

• Salesforce Help, Considerations for Object Relationships (opens in a new tab), på engelsk, kontrolleret 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, kontrolleret 2026-10-13.
• Salesforce Help, Roll-Up Summary Field (opens in a new tab), på engelsk, kontrolleret 2026-10-13.
• Salesforce Developers, Metadata API, ApprovalProcess (opens in a new tab), på engelsk, kontrolleret 2026-10-13.
• Salesforce Help, Lookup Filters (opens in a new tab), på engelsk, kontrolleret 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, kontrolleret 2026-10-02.
• Salesforce Developers, Designing Record Access for Enterprise Scale, Parent-Child Data Skew (opens in a new tab), på engelsk, kontrolleret 2026-10-02.